On Fri, Apr 12, 2013 at 9:55 AM, Erin Noe-Payne <[email protected]>wrote:
> 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 > resources. > > - 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 I look forward to trying it out. Out of curiosity, have you put any thought into how security will work? For example, can I restrict people to particular contexts? How will that work client side? Chris
