<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 19, 2015 at 3:11 PM, Zack Galbreath <span dir="ltr"><<a href="mailto:zack.galbreath@kitware.com" target="_blank">zack.galbreath@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi everybody,<div><br></div><div>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.</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>I really like this idea, and I know others will really like it as well. Do we have funding to accomplish a rewrite of this scale? Are we trying to gather more contributors to have more eyes and/or hands on the rewrite?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Here's a link to a proof-of-concept branch where I've converted the viewBuildError page to use AngularJS instead of XSLT:</div><div><a href="https://github.com/Kitware/CDash/compare/viewBuildError_angular" target="_blank">https://github.com/Kitware/CDash/compare/viewBuildError_angular</a><br></div><div>Notice how this transition could safely occur one page at a time.<br></div><div><br></div><div>Your probably thinking at this point, why Angular?</div><div><br></div><div>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.</div><div><br></div><div>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: <a href="http://thesmithfam.org/blog/2012/12/02/angularjs-is-too-humble-to-say-youre-doing-it-wrong/" target="_blank">http://thesmithfam.org/blog/2012/12/02/angularjs-is-too-humble-to-say-youre-doing-it-wrong/</a></div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>Maybe I don't fully understand this, but I don't believe this is what the two-way data binding concept in Angular implies. My understanding of the two-way binding is that editing something in the DOM would also update its javascript model representation automatically. To achieve dynamic updates from the server you'd still have to do some kind of polling (simple polling, SSE long polling, websocket long polling, etc.) Without two-way data binding, you'd have to listen to change events in the DOM and update the model yourself. I might be wrong though, please provide me with a link to docs to educate me if so :) This is by no means saying we shouldn't use Angular, just making sure we understand why we would choose it versus other similar libraries.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Thanks for reading this far.  Please share any ideas, questions, or concerns that you might have at this point.</div></div>
<br>_______________________________________________<br>
Cdash mailing list<br>
<a href="mailto:Cdash@public.kitware.com">Cdash@public.kitware.com</a><br>
<a href="http://public.kitware.com/mailman/listinfo/cdash" target="_blank">http://public.kitware.com/mailman/listinfo/cdash</a><br>
<br></blockquote></div><br>I'm glad someone is taking a crack at this and am very interested in this effort.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,<br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Zach Mullen<br>Kitware, Inc.<br>919-869-8858</div></div></div></div>
</div></div>