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 Mon, 29 Apr 2013 15:43:13 GMT
+1 for building on trunk and merging into branch - works for me.

 - What is the difference between organizations and groups? I couldn't
find any info looking through JIRA.
 - Mongodb and sql db's sort have a conflicting stance on
normalization, which might explain why they are currently treated as
properties. I generally agree that we should manage them separately
but it might be worth thinking through all the cases where we retrieve
a user and how often we would expect org / group info to come along
with it.

On Mon, Apr 29, 2013 at 11:09 AM, Chris Geer <chris@cxtsoftware.com> wrote:
> On Mon, Apr 29, 2013 at 4:52 AM, Matt Franklin <m.ben.franklin@gmail.com>wrote:
>
>> On Fri, Apr 26, 2013 at 3:46 PM, Erin Noe-Payne <erin.noe.payne@gmail.com
>> >wrote:
>>
>> > 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.
>> >
>>
>> Since the APIs are functionally separate, I think we should work them in
>> trunk and merge them into the branch.  I will hopefully have time to fix
>> the mongo issues for 0.21.1 today and can start the APIs later.  Anyone
>> else have time?
>>
>
> I agree we should work on them in trunk and merge them back into the
> branch. I don't have time but I need to make time. I'll continue work on
> them this week.
>
> On that note, I went to create APIs for Organizations and Groups and
> realized there is no backend repository for either of those. They are just
> attributes on person/user. My personal belief is that we should
> have separate management of both groups and organizations since those
> should really exist before a user, and have users assigned to them. Any
> objections?
>
> Chris
>
>>
>>
>> >
>> > Erin
>> >
>> > 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
>> > 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.
>> > >>>
>> > >>
>> > >> 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
>> > >>>
>> >
>>

Mime
View raw message