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

> On Wed, Jun 5, 2013 at 4:49 PM, Matt Franklin <m.ben.franklin@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.
> >>
> >
> > 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.
> >
>
> To be honest I'm not super familiar with what the current security
> model looks like. But from the perspective of writing angular
> applications that consume the api, my expectations would be:
>
> - I have restful endpoints to login and logout
> - Every request I make against the api will correctly return 401 or
> 403 status codes if there is any authentication problem.
> - My app can then intercept these codes and properly redirect the UI
> to login page / not authorized warning.
>

Erin, yes, from the UI perspective that is a pretty good viewpoint. From
the server perspective though there is some more thought that is needed.
For example, should every user on system be able to get all the attributes
about every person? Should a friend be able to see more details than
another random person? The server needs to be able to have a model where
decisions can be made on more than just is this person a normal user or an
admin. The UI also needs to be able to handle that as well. For example, is
you aren't frieds with someone certain fields may come back as null. Not a
huge deal but a consideration.

The reason security is so important on the server side is once you move the
UI to the client side you can no longer trust the client side because there
is no guarantee that the request is coming from our client.  At least with
the JSP model we could count of the view filtering data if needed, now we
have to do it in the web services directly.

Chris

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