rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Geer <ch...@cxtsoftware.com>
Subject Re: Moving rave portal to angularjs
Date Mon, 01 Apr 2013 21:23:39 GMT
On Mon, Apr 1, 2013 at 1:36 PM, Erin Noe-Payne <erin.noe.payne@gmail.com>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.

+1 for branch. I concur with Matt that this won't be 100% by 0.22 (web
services might not be there by then) so we should isolate.  Even if it is
ready...I think we should bake it fully before rip/replace. (wouldn't it be
nice if we had a git repo? :)  If we do this in a branch there is very
little reason not to move forward since we don't have to decide if it's a
replacement or not until it's complete.

We probably want to post a warning on the 0.21 (and future) release(s)
stating that the Backbone/handlars code will be going away in the future so
to use at risk.

> 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.

I guess I'm less concerned about this now after looking more closely at the
code we currently have. I was under the impression that the Backbone model
was going to part of the core, not part of the portal, and it could be used
by various portal implementations. Since it's not, there is less of a
chance of people being dependent on it.

> 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.
>     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.
> >>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message