rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Geer <ch...@cxtsoftware.com>
Subject Re: [Discuss] Rave & Angular strategy
Date Wed, 05 Jun 2013 16:53:35 GMT
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?

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message