On 7/5/16 9:00 AM, Alejandro Galue wrote: > My goal for the DevJam 2016 is remove all the GWT related pages, and > replace them with their AngularJS versions (even if that means add some > improvements to the ReST API).
+1. I think everyone agrees that the piecemeal GWT components need to be replaced and I think that Angular is a perfect solution for that since (a) it's easily embeddable in the places that we use GWT and (b) almost everything it needs to display is already available over REST (interface lists on node page, resource lists for graph picker). > My second goal is to standardize and normalize the JavaScript > dependencies in OpenNMS WebApp in order to have common > NodeJS/Bower/Karma/* configuration, and treat all the JS dependencies > like AngularJS as we do with any Java library with Maven. +10. My blood pressure rises slightly every hour I do JS development without a test framework in place to save me from the many bugs that I am surely writing. > In my personal opinion, it is a waste of time and resources to develop > with Vaadin. It is drastically faster, enjoyable and more easy to use > any JS library like AngularJS, specially for testing, but unfortunately, > the main views we have with Vaadin require lots of changes to expose the > required information through ReST in order to replace them with > AngularJS, but I hope this can change in the future. This is a serious problem that we need to address. In the past, our "model" objects were well-defined because they were tied directly to an XML file (configs) or a database table (Hibernate DAO). For new systems, the model objects are Java classes that aren't necessarily mapped to persistent storage (ie. topology). However, we still need a way to retrieve/manipulate these objects via REST so that Angular/*.js can access them easily to produce UI elements. I feel like in these cases, using Vaadin was like a prototyping step because by using it, we didn't need to strictly separate the model, map it to JAXB, then make a REST interface out of it while 5 people are working on a UI on top of it. So maybe that was OK. To use topology as an example, now that its code is more mature, we should extract its model and treat it as relatively frozen (as frozen as any other model object, like OnmsNode) so that we can wrap a REST interface around it. Then we'll have the ability to use JS to refactor the UI and it will give devops people an easy way to hook into the topology API. Would it have been faster to go REST-first with the topology UI if we were starting out on it today (and had the JS/REST experience that we have now)? Definitely. So that's probably how we should work on new projects. My $0.02, Seth
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape
_______________________________________________ Please read the OpenNMS Mailing List FAQ: http://www.opennms.org/index.php/Mailing_List_FAQ opennms-devel mailing list To *unsubscribe* or change your subscription options, see the bottom of this page: https://lists.sourceforge.net/lists/listinfo/opennms-devel
