rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Geer <ch...@cxtsoftware.com>
Subject Re: Angular branch
Date Fri, 12 Apr 2013 17:02:58 GMT
On Fri, Apr 12, 2013 at 9:55 AM, Erin Noe-Payne <erin.noe.payne@gmail.com>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

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