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 Fri, 07 Jun 2013 20:58:18 GMT
On Wed, Jun 5, 2013 at 2:41 PM, Chris Geer <chris@cxtsoftware.com> wrote:

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

To reply to myself here....moving to a web service model, what
authentication approach were you planning on using? Since we'll be
deprecating the form based authentication, will we just move to basic
authentication?

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