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

>
>>
>> >
>> > - 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
View raw message