On Wed, Jun 5, 2013 at 2:03 PM, Erin Noe-Payne <[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. > > > >> > >> - 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? > > Yes you can base your gadgets on angular, as far as I know there is > not currently a way to optimize. The gadgets are iframes, memory > segregated, don't care about what the container does. > Though, I could see the case for a straight angular widget provider that just integrates into the page and relies on local APIs. Of course there are risks to using such a widget, but there might be a few use cases where it makes sense. > > > > >> > >> - 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. > > > >> > >> - 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. > > > >> > >> Let me know what you think. > >> Thanks, > >> Erin > >> >
