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 Angular branch
Date Fri, 12 Apr 2013 16:55:21 GMT
Hey all, I've pushed the first couple commits to the angular branch
with some extremely basic features in place. I want to start a
discussion to refine our vision for the portal application and keep
everyone on the same page.

To preview the work so far:
- Check out from https://svn.apache.org/repos/asf/rave/branches/angular/
- Spin up rave
- Hit the url http://localhost:8080/portal/app/angular/portal

You should see some tabs that you can navigate between, some rendered
widgets. Very little else is working at this point.

The proposal:
- An implementer should be able to define any custom context that they
want to present through the rave portal application. This corresponds
to the context as we discussed in the pages api [1]. Currently rave
ships with "portal" and "profile" contexts, and that's what I will be
building out.

- Each context gets its own angular 'single-page' web application.
Moving within a context (IE /profile/erin -> /profile/matt) is all
client side routing & ajax calls. Moving between contexts (/profile ->
/portal) is a full page reload and entirely new angular webapp is
served. The reason for this structure is that each context will want
its own display (markup & css), its own routing rules, etc.

- The contexts are served from one generic endpoint. Right now this is
/portal/app/angular/{context}/** to avoid collision with other
endpoints. Eventually I see this as moving to root and replacing most
of our current application endpoints. See
org.apache.rave.portal.web.controller.AngularController for the basic
implementation. The idea is that a call to the context endpoint will
always render the same basic view that imports the corresponding
context's markup and angular js app, and that app then handles any
further navigation / client side routing / importing of appropriate

- In this way, the implementation of a context is entirely in static
files - html, css, js. If an implementer wants to add a new context
(say portfolio), they only need to create the new static files to
support that context. This means that a new context can be custom
built from the ground up without having to overlay and with complete
flexibility. However...

- We can still write and provide reusable components. View partials
can be imported using angular's ng-include blocks, common services can
be written as angular modules.

[1] http://mail-archives.apache.org/mod_mbox/rave-dev/201303.mbox/browser

View raw message