[Cdash] rewriting CDash's frontend

[Sebastien Jourdain]

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cdash/attachments/20150319/c8be81f3/attachment-0001.html>