On Wed, Jun 5, 2013 at 2:41 PM, Chris Geer <[email protected]> wrote:
> On Wed, Jun 5, 2013 at 2:21 PM, Erin Noe-Payne > <[email protected]>wrote: > >> On Wed, Jun 5, 2013 at 4:49 PM, Matt Franklin <[email protected]> >> wrote: >> > On Wed, Jun 5, 2013 at 12:53 PM, Chris Geer <[email protected]> >> wrote: >> > >> >> On Wed, Jun 5, 2013 at 9:06 AM, Erin Noe-Payne < >> [email protected] >> >> >wrote: >> >> >> >> > Hey All, >> >> > >> >> > Over the last couple months I have been working in the angular branch >> >> > to develop a strategy for updating rave portal to function as a more >> >> > flexible application that delivers the same current functionality out >> >> > of the box, but provides a more generic model for extension and >> >> > treatment of new contexts. I want to outline that vision here and try >> >> > to describe what it would mean to develop in rave under this >> paradigm. >> >> > This would mean breaking changes for future versions of rave, so I >> >> > want feedback. Would this make sense for how you use rave? What's >> >> > good, what's bad? >> >> > >> >> > The proposal: >> >> > >> >> > - The server deals entirely in data through rest api's. Anything that >> >> > the rave portal ui currently does should be accessible & modifiable >> >> > through a rest api. >> >> > >> >> >> >> +1 - my only concern right now is security. Rave doesn't have a very >> robust >> >> security model right now as there is really only User and Admin. I >> think we >> >> need to expand this to include groups (we can use the existing groups >> as >> >> those aren't even used anywhere) and some security based on friends. >> >> >> > >> > This should be enforced via the API, so we should be able to grow out >> the >> > security model there. Right now it is very model oriented with, as you >> > note, the only two roles being defined as user & admin. >> > >> >> To be honest I'm not super familiar with what the current security >> model looks like. But from the perspective of writing angular >> applications that consume the api, my expectations would be: >> >> - I have restful endpoints to login and logout >> - Every request I make against the api will correctly return 401 or >> 403 status codes if there is any authentication problem. >> - My app can then intercept these codes and properly redirect the UI >> to login page / not authorized warning. >> > > Erin, yes, from the UI perspective that is a pretty good viewpoint. From > the server perspective though there is some more thought that is needed. > For example, should every user on system be able to get all the attributes > about every person? Should a friend be able to see more details than > another random person? The server needs to be able to have a model where > decisions can be made on more than just is this person a normal user or an > admin. The UI also needs to be able to handle that as well. For example, is > you aren't frieds with someone certain fields may come back as null. Not a > huge deal but a consideration. > > The reason security is so important on the server side is once you move > the UI to the client side you can no longer trust the client side because > there is no guarantee that the request is coming from our client. At least > with the JSP model we could count of the view filtering data if needed, now > we have to do it in the web services directly. > To reply to myself here....moving to a web service model, what authentication approach were you planning on using? Since we'll be deprecating the form based authentication, will we just move to basic authentication? > > Chris > >> >> > >> >> >> >> > >> >> > - No more jsp's. Probably no more server-side view composition at >> all. >> >> > The views are served entirely as static files - html, js, css - and >> >> > composition and routing are handled client-side via angular.js >> >> > >> >> >> >> +1 - What I want to know is can I run an angular based gadget inside >> the >> >> angular based Rave? Does that even make sense, and is there anyway >> >> to optimize it? >> >> >> >> > >> >> > - Rave ships with a portal and a profile context. Each context >> >> > represents a workspace and has complete ownership of its own >> branding, >> >> > navigation, etc. If you want to add a new context X it should involve >> >> > no overlay, just extension. >> >> > -- In terms of data, you will simply add new pages with a context of >> >> > X, and the api will deliver them. >> >> > -- In terms of ui and routing, the portal application has a wildcard >> >> > endpoint that looks like "/{context}/**". Out of the box, {context} >> >> > will be matched against a directory at static/html/{context}. So you >> >> > just add static/html/X. This will serve up an angularjs single-page >> >> > app that displays its own ui, manages its own routing etc. This gives >> >> > us complete flexibility and customizability for any new context. >> Also, >> >> > because the static content is simply being served from a url, it >> could >> >> > just as easily be coming from a cms or another server as from the >> >> > portal's static directory. >> >> > >> >> >> >> +0 - I guess I still don't fully understand the whole context concept >> so I >> >> just need to look into it more. >> >> >> > >> > A context to me is just a workspace that allows you to define a specific >> > function that the UI is to perform. From there the data model of Rave >> is >> > used to manage widgets within the construct of the context. For >> instance, >> > profile & portal are contexts. You could also have group, project, >> site, >> > organization or other top level contexts. >> > >> > >> >> >> >> > >> >> > - To support that flexibility but still stay DRY, view components (in >> >> > angular-speak that is directives and templates, which are roughly >> >> > analogous to jsp tags) will be modular and re-usable. So components >> >> > that we provide in the out of the box contexts like navigation or >> >> > widget chrome should be directives that can be require()'d and >> re-used >> >> > by your new custom context. Likewise you should be able to write and >> >> > share any custom directives between your various contexts. >> >> > >> >> >> >> +1 >> >> >> >> > >> >> > - To knit everything together I think we will need an AMD script >> loader, >> >> > probably require.js. This would allow your custom context to easily >> >> > build out a dependency tree, get the features it needs for its >> context >> >> > without any extra weight, and to optimize / concat / minify resources >> >> > for each context. >> >> > >> >> >> >> +0 - If it's needed get it. >> >> >> > >> > There is a very nice performance benefit to using an AMD loader, >> especially >> > if we have a strong set of lifecycle events in the application. It >> should >> > allow us to start initializing widgets earlier and make a "snappier" UI. >> > >> > >> > >> >> >> >> > >> >> > Let me know what you think. >> >> > Thanks, >> >> > Erin >> >> > >> >> >> > >
