[Cdash] rewriting CDash's frontend
sebastien.jourdain at kitware.com
Thu Mar 19 19:31:16 UTC 2015
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.
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.
> 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:
>> 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:
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the CDash