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:44:35 GMT
On Wed, Jun 5, 2013 at 2:03 PM, Erin Noe-Payne <erin.noe.payne@gmail.com>wrote:

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

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

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