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 Mon, 29 Apr 2013 16:26:45 GMT
On Mon, Apr 29, 2013 at 8:43 AM, Erin Noe-Payne <erin.noe.payne@gmail.com>wrote:

> +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.
>

Groups are for security, Organizations are arbitrary items...like business
units


>  - 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message