rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Franklin <m.ben.frank...@gmail.com>
Subject Re: [Discuss] Rave & Angular strategy
Date Wed, 05 Jun 2013 20:49:41 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.
>

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.


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

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