Moving rave portal to angularjs

[Erin Noe-Payne <er...@gmail.com>]

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.

Re: Moving rave portal to angularjs

[Matt Franklin <m....@gmail.com>]

On Mon, Apr 1, 2013 at 4:25 PM, Chris Geer <ch...@cxtsoftware.com> wrote:

> Link to the JIRA discussion [1]
>
> [1] https://issues.apache.org/jira/browse/RAVE-941


You raise a good point regarding the backbone views.  Hopefully, the
solution we come up with will be easily mapped.  My biggest concern is that
we won't have it in good enough shape before the next release.  I think a
branch might be a good spot to work the client MVC approach.  We can still
work the core API and JSP simplification in the trunk.


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

Re: Moving rave portal to angularjs

[Matt Franklin <m....@gmail.com>]

On Mon, Apr 1, 2013 at 4:36 PM, Erin Noe-Payne <er...@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.
>
> 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 <ch...@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.
> >>
>

Re: Moving rave portal to angularjs

[Chris Geer <ch...@cxtsoftware.com>]

On Mon, Apr 1, 2013 at 1:36 PM, Erin Noe-Payne <er...@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 <ch...@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.
> >>
>

Re: Moving rave portal to angularjs

[Erin Noe-Payne <er...@gmail.com>]

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.
    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 <ch...@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 <er...@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.
>>

Re: Moving rave portal to angularjs

[Chris Geer <ch...@cxtsoftware.com>]

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

Re: Moving rave portal to angularjs

[Matt Franklin <m....@gmail.com>]

On Mon, Apr 1, 2013 at 4:18 PM, Erin Noe-Payne <er...@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.
>

I think there will need to be some form of server-side composition, but it
should be MUCH less cumbersome that it is currently.


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

+1