On Fri, Apr 12, 2013 at 1:02 PM, Chris Geer <[email protected]> wrote:
> 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?
>
Definitely. So from the server side perspective we can continue to use
spring or whatever other security provider we want. We could force
someone to login before they can hit the {context} endpoint at all -
you'll see that is the case now but I don't really have an opinion on
that. I think where you put your security restrictions is on the api
endpoints that deliver data.
Then from the application perspective, any angular webapp that loads
in a particular context will need to make api calls to get data. You
can then write an http interceptor so that for any call that is
intercepted with a 401, some action is taken. There is a simple
example of this in the code right now in
script/angular-portal/routing.js lines 22- 41 (note you can't actually
see it in action because our endpoints don't return 401, and you have
to be logged in to see the context endpoint at all). This is a simple
implementation that assumes that if you receive a 401 you are simply
not logged in, and get redirected to a login page. But you can easily
take a more granular approach, and we can provide this as a pluggable
authentication service that each context webapp can configure and use
as they see fit.
> Chris
