On Mon, Apr 1, 2013 at 4:36 PM, Erin Noe-Payne <[email protected]>wrote:
> Addressing Chris's comments from that discussion - > > 1) Does it make sense that we do something like this as a sandbox > effort/branch and flip the switch in the future? > In terms of branching, I can go either way. As an angular app it > is only looking to serve html, so we can easily build out the angular > app along a different set of url paths than the current portal much as > we are doing with the rest apis. It may be weird to deliver that > incomplete content as part of the trunk though. > > 2) The other big question is what happens to the Backbone stuff that > was just added? > If we go the route of using angular I will end up backing out > backbone and handlebars and pass control of all state management & > client side templating over to angular. > > 3) Overall I support using something like AngularJS as the framework > but I thought we had ruled that out. If it ends up being a better fit > I agree we should consider going for it but my concern is the timing. > We are on the verge of releasing 0.21 where we just implemented a new > JS API with Backbone and Handlebars and we are talking about ripping > it out already. This poses problems for implementors who are trying to > keep up with recent versions of Rave because it requires quite a bit > of rework (at least potentially). > I had initially argued against using angular or another > opinionated mvc framework on the premise that it would be difficult to > integrate with raves dependencies, especially the shindig and wookie > providers. Since then we have isolated these dependencies into the > rave core module, and I see angular as a much better fit. In general > my initial submission using backbone and handlebars was attempting to > address issues with the portal before dealing with the core. I think > that was not the best approach, but it was submitted before our > discussions at apachecon in which we changed the direction of the > refactor to focus on separating portal & core and focusing on better > apis. > Having spent time with Angular for the first time at the Hackathon, I think it will fit well with the new abstracted model. I do think that we should give those committers who have an interest in making it happen the time to do it properly before mashing it into the trunk. > The second concern is valid - this is creating back and forth work > for implementers who are trying to keep up with the latest rave > releases with respect to Backbone and Handlebars integration (but not > the core js api - there is no suggestion to drop those changes). I'm > open to suggestions or looking at a different time frame, but I do > believe that this will be the right approach. > On Mon, Apr 1, 2013 at 4:25 PM, Chris Geer <[email protected]> wrote: > > Link to the JIRA discussion [1] > > > > [1] https://issues.apache.org/jira/browse/RAVE-941 > > > > > > On Mon, Apr 1, 2013 at 1:18 PM, Erin Noe-Payne <[email protected] > >wrote: > > > >> Hi All - this discussion was started as a Jira ticket. I'm moving to the > >> dev list per Chris's request. > >> > >> With RAVE-914 we now have the rave core functionality isolated from the > >> portal. This allows us to refactor the portal application and write it > as a > >> reference implementation on top of the rave core with the following > goals: > >> - Support generic data contexts for pages - portal, profile, portfolio > or > >> whatever else. No more hard coded portal page vs profile page. > >> - Allow implementers to extend the portal application with less > reliance on > >> overlays. > >> - Move away from jsps or other heavy-lifting view rendering logic from > the > >> server. > >> > >> I'm proposing to use angularjs (http://angularjs.org/) as a client side > >> mvc > >> framework. This would be in place of previous efforts to implement the > >> portal using backbonejs and handlebars. Basic roadmap: > >> - Move away from jsp's, either moving to a lighter-weight rendering > >> framework or consider serving only raw html with no rendering framework > on > >> the server at all. > >> - Rewrite / update portal's views as angularjs compatible markup. > >> - Write the portal js as an angularjs application that interacts with > the > >> rave core. > >> - Use the new rest apis to serve data for client side navigation and > >> partial view loads. > >> - Allow implementers to extend rave portaljs for custom functionality > >> without overlaying, allow them to add views for new custom contexts > without > >> requiring overlays. > >> >
