[Cdash] rewriting CDash's frontend

[David E DeMarle]

+1

I'ld like to get different primary view types in in this incarnation.

The primary view we have now is great for showing what machines have
problems, but it isn't the best way to present the result to show what
tests are problematic or what variables each submission is actually testing.

I'm happy to help, if I can get the time to do so.

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Thu, Mar 19, 2015 at 3:31 PM, Sebastien Jourdain <
sebastien.jourdain at kitware.com> wrote:

> As a side note, I also think that AngularJS is a good match for CDash.
> Between the filters, search and query, you will get a lot for free.
>
> Zach M is right the two way binding won't give you automatic update, but
> it will simplify the way the page get updated under the cover. A polling
> will still be needed, but the server API can take that into account and
> allow to get only the delta/new builds... And at that point you just need
> to update your model and Angular will do the rest.
>
> Seb
>
> On Thu, Mar 19, 2015 at 1:21 PM, Sebastien Jourdain <
> sebastien.jourdain at kitware.com> wrote:
>
>> Hi Zach,
>>
>> That's great. I'm looking forward to see that evolution.
>>
>> Seb
>>
>> On Thu, Mar 19, 2015 at 1:11 PM, Zack Galbreath <
>> zack.galbreath at kitware.com> wrote:
>>
>>> Hi everybody,
>>>
>>> I think we should rewrite CDash's frontend using AngularJS.  The
>>> overarching goal is to make it easier to add new features, visualizations,
>>> and plugins to CDash.  We want you to be able to get more value out of your
>>> build data, and we want to make it easier for you to interact with CDash.
>>>
>>> To accomplish this, we should define a REST API for sending & receiving
>>> data to & from CDash.  Internally CDash should use this API exclusively so
>>> we don't have to maintain two separate data paths.  Another benefit of this
>>> change would be making development easier & more pleasant by removing XSLT
>>> from CDash.  Once we have a stable API in place, we could safely make
>>> sweeping changes to CDash's backend without fear of breaking the app.
>>>
>>> Here's a link to a proof-of-concept branch where I've converted the
>>> viewBuildError page to use AngularJS instead of XSLT:
>>> https://github.com/Kitware/CDash/compare/viewBuildError_angular
>>> Notice how this transition could safely occur one page at a time.
>>>
>>> Your probably thinking at this point, why Angular?
>>>
>>> For frontend development, I like the idea of writing code as close to
>>> HTML as possible, but with the added power of dynamically loaded data,
>>> conditionals, and loops.
>>>
>>> I looked into other client-side templating engines and they didn't seem
>>> as simple or clean to me.  For more on this point, here's a relatively old
>>> blog post that sums up my feelings pretty well:
>>> http://thesmithfam.org/blog/2012/12/02/angularjs-is-too-humble-to-say-youre-doing-it-wrong/
>>>
>>> Angular also comes with two-way binding.  This means that new builds
>>> could appear on index.php as they roll in without you having to refresh
>>> your page.
>>>
>>> I realize that Angular 2.0 is on the horizon.  That's scary, but I don't
>>> think it should prevent us from using the best tools at our disposal.
>>> Perhaps it's misguided, but my plan is to use Angular primarily for its
>>> templating engine, and keep as much logic as possible in PHP.  My hope is
>>> that by minimizing the amount of Angular-specific code that we write,
>>> upgrading to 2.0 (if we decide to do that) won't be as difficult as feared.
>>>
>>> Thanks for reading this far.  Please share any ideas, questions, or
>>> concerns that you might have at this point.
>>>
>>> _______________________________________________
>>> Cdash mailing list
>>> Cdash at public.kitware.com
>>> http://public.kitware.com/mailman/listinfo/cdash
>>>
>>>
>>
>
> _______________________________________________
> Cdash mailing list
> Cdash at public.kitware.com
> http://public.kitware.com/mailman/listinfo/cdash
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cdash/attachments/20150319/5878c145/attachment.html>