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: [Discuss] Rave & Angular strategy
Date Wed, 05 Jun 2013 18:03:14 GMT
On Wed, Jun 5, 2013 at 12:53 PM, Chris Geer <chris@cxtsoftware.com> wrote:
> On Wed, Jun 5, 2013 at 9:06 AM, Erin Noe-Payne <erin.noe.payne@gmail.com>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.

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

View raw message