[Discuss] Rave & Angular strategy

[Erin Noe-Payne <er...@gmail.com>]

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.

- 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

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

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

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

Let me know what you think.
Thanks,
Erin

Re: [Discuss] Rave & Angular strategy

[Matt Franklin <m....@gmail.com>]

On Mon, Jun 10, 2013 at 1:03 PM, Erin Noe-Payne <er...@gmail.com>wrote:

> Matt, I don't entirely follow the authentication piece. What do you
> mean that the login form is hosted by the api server? My thought is
> that each context, if it needs to be behind authentication, will
> implement an authentication http interceptor so that any data requests
> that fail due to a 401 will redirect to the login form. Rave should
> ship a generic login form with each context able to override with a
> custom implementation. The login form can post to a validation
> endpoint that returns an api key for making requests going forward.
>

In essence, this is what I am suggesting; but, rather than specifically tie
it to a context, we will want to be able to support multiple contexts from
the same API server.

The biggest difference is using OAuth 2 implicit flow for API
authorization.  It will act much like an API key (authorization token);
but, uses the OAuth 2 protocol to manage TTL & authentication.


>
> I agree that user management, widget store and admin will all end up
> being separate from the "context" system. I figured we would end up
> writing these out as angular apps as well.
>

+1.  They are less critical; but, we should make sure we are using
consistent UI frameworks.


>
> On Fri, Jun 7, 2013 at 6:31 PM, Matt Franklin <m....@gmail.com>
> wrote:
> > On Fri, Jun 7, 2013 at 5:57 PM, Chris Geer <ch...@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 <ch...@cxtsoftware.com>
> >> wrote:
> >> >
> >> > > On Wed, Jun 5, 2013 at 2:41 PM, Chris Geer <ch...@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
> >> > > >> >> >
> >> > > >> >>
> >> > > >>
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
>

Re: [Discuss] Rave & Angular strategy

[Erin Noe-Payne <er...@gmail.com>]

Matt, I don't entirely follow the authentication piece. What do you
mean that the login form is hosted by the api server? My thought is
that each context, if it needs to be behind authentication, will
implement an authentication http interceptor so that any data requests
that fail due to a 401 will redirect to the login form. Rave should
ship a generic login form with each context able to override with a
custom implementation. The login form can post to a validation
endpoint that returns an api key for making requests going forward.

I agree that user management, widget store and admin will all end up
being separate from the "context" system. I figured we would end up
writing these out as angular apps as well.

On Fri, Jun 7, 2013 at 6:31 PM, Matt Franklin <m....@gmail.com> wrote:
> On Fri, Jun 7, 2013 at 5:57 PM, Chris Geer <ch...@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 <ch...@cxtsoftware.com>
>> wrote:
>> >
>> > > On Wed, Jun 5, 2013 at 2:41 PM, Chris Geer <ch...@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
>> > > >> >> >
>> > > >> >>
>> > > >>
>> > > >
>> > > >
>> > >
>> >
>>

Re: [Discuss] Rave & Angular strategy

[Matt Franklin <m....@gmail.com>]

On Fri, Jun 7, 2013 at 5:57 PM, Chris Geer <ch...@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 <ch...@cxtsoftware.com>
> wrote:
> >
> > > On Wed, Jun 5, 2013 at 2:41 PM, Chris Geer <ch...@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
> > > >> >> >
> > > >> >>
> > > >>
> > > >
> > > >
> > >
> >
>

Re: [Discuss] Rave & Angular strategy

[Chris Geer <ch...@cxtsoftware.com>]

On Fri, Jun 7, 2013 at 2:46 PM, Matt Franklin <m....@gmail.com>wrote:

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

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

Re: [Discuss] Rave & Angular strategy

[Matt Franklin <m....@gmail.com>]

On Fri, Jun 7, 2013 at 4:58 PM, Chris Geer <ch...@cxtsoftware.com> wrote:

> On Wed, Jun 5, 2013 at 2:41 PM, Chris Geer <ch...@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 <ch...@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.


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

Re: [Discuss] Rave & Angular strategy

[Chris Geer <ch...@cxtsoftware.com>]

On Wed, Jun 5, 2013 at 2:41 PM, Chris Geer <ch...@cxtsoftware.com> wrote:

> On Wed, Jun 5, 2013 at 2:21 PM, Erin Noe-Payne <er...@gmail.com>wrote:
>
>> On Wed, Jun 5, 2013 at 4:49 PM, Matt Franklin <m....@gmail.com>
>> wrote:
>> > On Wed, Jun 5, 2013 at 12:53 PM, Chris Geer <ch...@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
>> >> >
>> >>
>>
>
>

Re: [Discuss] Rave & Angular strategy

[Chris Geer <ch...@cxtsoftware.com>]

On Wed, Jun 5, 2013 at 2:21 PM, Erin Noe-Payne <er...@gmail.com>wrote:

> On Wed, Jun 5, 2013 at 4:49 PM, Matt Franklin <m....@gmail.com>
> wrote:
> > On Wed, Jun 5, 2013 at 12:53 PM, Chris Geer <ch...@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
> >> >
> >>
>

Re: [Discuss] Rave & Angular strategy

[Erin Noe-Payne <er...@gmail.com>]

On Wed, Jun 5, 2013 at 4:49 PM, Matt Franklin <m....@gmail.com> wrote:
> On Wed, Jun 5, 2013 at 12:53 PM, Chris Geer <ch...@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
>> >
>>

Re: [Discuss] Rave & Angular strategy

[Matt Franklin <m....@gmail.com>]

On Wed, Jun 5, 2013 at 12:53 PM, Chris Geer <ch...@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.


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

Re: [Discuss] Rave & Angular strategy

[Matt Franklin <m....@gmail.com>]

On Wed, Jun 5, 2013 at 2:03 PM, Erin Noe-Payne <er...@gmail.com>wrote:

> On Wed, Jun 5, 2013 at 12:53 PM, Chris Geer <ch...@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
> >>
>

Re: [Discuss] Rave & Angular strategy

[Erin Noe-Payne <er...@gmail.com>]

On Wed, Jun 5, 2013 at 12:53 PM, Chris Geer <ch...@cxtsoftware.com> wrote:
> On Wed, Jun 5, 2013 at 9:06 AM, Erin Noe-Payne <er...@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.

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

Re: [Discuss] Rave & Angular strategy

[Chris Geer <ch...@cxtsoftware.com>]

On Wed, Jun 5, 2013 at 9:06 AM, Erin Noe-Payne <er...@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?

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