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 [Discuss] Rave & Angular strategy
Date Wed, 05 Jun 2013 16:06:58 GMT
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.

- 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

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

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

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

Let me know what you think.
Thanks,
Erin

Mime
View raw message