rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erin Noe-Payne <erin.noe.pa...@gmail.com>
Subject Re: Moving rave portal to angularjs
Date Mon, 01 Apr 2013 20:36:24 GMT
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
    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 <chris@cxtsoftware.com> 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 <erin.noe.payne@gmail.com>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.

View raw message