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 Fri, 07 Jun 2013 22:31:11 GMT
On Fri, Jun 7, 2013 at 5:57 PM, Chris Geer <chris@cxtsoftware.com> wrote:

> On Fri, Jun 7, 2013 at 2:46 PM, Matt Franklin <m.ben.franklin@gmail.com
> >wrote:
>
> > On Fri, Jun 7, 2013 at 4:58 PM, Chris Geer <chris@cxtsoftware.com>
> wrote:
> >
> > > 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?
> > >
> >
> > I am not sure deprecating the login form makes a ton of sense from the
> OOTB
> > portal.  I think it should be easily replaceable; but, it is nice to have
> > the user management/login from the OOTB perspective.  I would imagine
> that
> > the User login /management section of rave is configured as the URL that
> > the users are directed to login at.
> >
>
> There will still need to be a login form, just housed in angular I would
> assume. Which means there needs to be a way to authenticate users that
> angular can call as a web service that doesn't require posting a form. In
> addition to that, there needs to be a way to call the web services without
> using the UI at all which means OOTB there should be a non-form way of
> authenticating users.
>

The login form should be eventually angular; but, should be hosted on the
API server.   We can then use OAuth Implicit Grant for the client JS and
regular authorization grant for server-to-server.  If a deployment uses SSO
or other authentication means that doesn't require a login form, it doesn't
have to deploy that UI.

In general, I think the auth form, user management, widget store &
administration UIs become decoupled from the main application delivery UI
(and each other).


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