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 Re: Angular branch
Date Fri, 26 Apr 2013 19:46:04 GMT
Hey All,

I added a few tickets last week for the new rest api routes. If anyone
is available to help on the angular branch filling out the new rest
apis that would be extremely helpful.  In particular we need to
continue implementing the  pages api - most of this is just stubbed
out at the moment.  We will also need the users / authentication api
soon. We do have the old rpc routes that give a lot of the crud
functionality, but I don't want to spend too much time writing code to
plug in to the json rpc responses if we can have decent rest endpoints
in place.


On Fri, Apr 12, 2013 at 1:58 PM, Erin Noe-Payne
<erin.noe.payne@gmail.com> wrote:
> On Fri, Apr 12, 2013 at 1:24 PM, Chris Geer <chris@cxtsoftware.com> wrote:
>> On Fri, Apr 12, 2013 at 10:19 AM, Erin Noe-Payne
>> <erin.noe.payne@gmail.com>wrote:
>>> On Fri, Apr 12, 2013 at 1:02 PM, Chris Geer <chris@cxtsoftware.com> wrote:
>>> > 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
>>> >> /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.
>> Ya, I'm curious to know how to handle it client side, I'm good with server
>> side. Now that the server isn't rendering the pages, the client has to be
>> aware of permissions so it can show/hide the correct information. For
>> example, if a user doesn't have permission to view a certain page, the link
>> should even be an option. That means there needs to be a way to have the UI
>> get a list of all the permissions a user has and take those into
>> consideration. I know there are ways to do it, just curious if you've put
>> anything in place. Honestly right now the backend isn't really setup to
>> handle that though. We need a more flexible permissions framework probably.
>> We have the same problem in our system so on page load we cache all the
>> permissions a user has client side and then the JS can use that list to
>> make determinations.
> This is a good question and honestly I only have a vague idea of what
> it will look like. I think in this case your auth will need to be a
> rest service. It will probably end up being part of the users api and
> look something like the pages api with /api/users/@self.
>>> > Chris

View raw message