You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Erin Noe-Payne <er...@gmail.com> on 2013/04/12 18:55:21 UTC
Angular branch
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
Re: Angular branch
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Mon, Apr 29, 2013 at 8:43 AM, Erin Noe-Payne <er...@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 <ch...@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
> >> > <er...@gmail.com> wrote:
> >> > > On Fri, Apr 12, 2013 at 1:24 PM, Chris Geer <ch...@cxtsoftware.com>
> >> > wrote:
> >> > >> On Fri, Apr 12, 2013 at 10:19 AM, Erin Noe-Payne
> >> > >> <er...@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
> >> > >>>
> >> >
> >>
>
Re: Angular branch
Posted by Erin Noe-Payne <er...@gmail.com>.
+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 <ch...@cxtsoftware.com> wrote:
> On Mon, Apr 29, 2013 at 4:52 AM, Matt Franklin <m....@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
>> > <er...@gmail.com> wrote:
>> > > On Fri, Apr 12, 2013 at 1:24 PM, Chris Geer <ch...@cxtsoftware.com>
>> > wrote:
>> > >> On Fri, Apr 12, 2013 at 10:19 AM, Erin Noe-Payne
>> > >> <er...@gmail.com>wrote:
>> > >>
>> > >>> On Fri, Apr 12, 2013 at 1:02 PM, Chris Geer <ch...@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
>> > >>>
>> >
>>
Re: Angular branch
Posted by Matt Franklin <m....@gmail.com>.
On Mon, Apr 29, 2013 at 11:09 AM, Chris Geer <ch...@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?
>
Definitely agree on groups. Organizations I am ambivalent on.
>
> Chris
>
> >
> >
> > >
> > > Erin
> > >
> > > On Fri, Apr 12, 2013 at 1:58 PM, Erin Noe-Payne
> > > <er...@gmail.com> wrote:
> > > > On Fri, Apr 12, 2013 at 1:24 PM, Chris Geer <ch...@cxtsoftware.com>
> > > wrote:
> > > >> On Fri, Apr 12, 2013 at 10:19 AM, Erin Noe-Payne
> > > >> <er...@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
> > > >>>
> > >
> >
>
Re: Angular branch
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Mon, Apr 29, 2013 at 4:52 AM, Matt Franklin <m....@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
> > <er...@gmail.com> wrote:
> > > On Fri, Apr 12, 2013 at 1:24 PM, Chris Geer <ch...@cxtsoftware.com>
> > wrote:
> > >> On Fri, Apr 12, 2013 at 10:19 AM, Erin Noe-Payne
> > >> <er...@gmail.com>wrote:
> > >>
> > >>> On Fri, Apr 12, 2013 at 1:02 PM, Chris Geer <ch...@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
> > >>>
> >
>
Re: Angular branch
Posted by Matt Franklin <m....@gmail.com>.
On Fri, Apr 26, 2013 at 3:46 PM, Erin Noe-Payne <er...@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?
>
> Erin
>
> On Fri, Apr 12, 2013 at 1:58 PM, Erin Noe-Payne
> <er...@gmail.com> wrote:
> > On Fri, Apr 12, 2013 at 1:24 PM, Chris Geer <ch...@cxtsoftware.com>
> wrote:
> >> On Fri, Apr 12, 2013 at 10:19 AM, Erin Noe-Payne
> >> <er...@gmail.com>wrote:
> >>
> >>> On Fri, Apr 12, 2013 at 1:02 PM, Chris Geer <ch...@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
> >>>
>
Re: Angular branch
Posted by Erin Noe-Payne <er...@gmail.com>.
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.
Erin
On Fri, Apr 12, 2013 at 1:58 PM, Erin Noe-Payne
<er...@gmail.com> wrote:
> On Fri, Apr 12, 2013 at 1:24 PM, Chris Geer <ch...@cxtsoftware.com> wrote:
>> On Fri, Apr 12, 2013 at 10:19 AM, Erin Noe-Payne
>> <er...@gmail.com>wrote:
>>
>>> On Fri, Apr 12, 2013 at 1:02 PM, Chris Geer <ch...@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
>>>
Re: Angular branch
Posted by Erin Noe-Payne <er...@gmail.com>.
On Fri, Apr 12, 2013 at 1:24 PM, Chris Geer <ch...@cxtsoftware.com> wrote:
> On Fri, Apr 12, 2013 at 10:19 AM, Erin Noe-Payne
> <er...@gmail.com>wrote:
>
>> On Fri, Apr 12, 2013 at 1:02 PM, Chris Geer <ch...@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
>>
Re: Angular branch
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Fri, Apr 12, 2013 at 10:19 AM, Erin Noe-Payne
<er...@gmail.com>wrote:
> On Fri, Apr 12, 2013 at 1:02 PM, Chris Geer <ch...@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.
>
> > Chris
>
Re: Angular branch
Posted by Erin Noe-Payne <er...@gmail.com>.
On Fri, Apr 12, 2013 at 1:02 PM, Chris Geer <ch...@cxtsoftware.com> wrote:
> On Fri, Apr 12, 2013 at 9:55 AM, Erin Noe-Payne <er...@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.
> Chris
Re: Angular branch
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Fri, Apr 12, 2013 at 9:55 AM, Erin Noe-Payne <er...@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