Re: [Proposal] Adding context to widget and page definitions

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

To make sure we all think this is the right path, I created a patch that
demonstrates a page level property bag.  This bag can then be injected by
the to-be-written JS code into the widgets.

https://reviews.apache.org/r/15207

If no one has any issues, I will commit the above patch to trunk.


On Thu, Oct 31, 2013 at 5:26 PM, Matt Franklin <m....@gmail.com>wrote:

> On Mon, Oct 28, 2013 at 1:14 AM, Erin Noe-Payne <er...@gmail.com>wrote:
>
>> On Wed, Oct 16, 2013 at 12:53 PM, Matt Franklin
>> <m....@gmail.com> wrote:
>> > On Wed, Oct 16, 2013 at 2:31 PM, Chris Geer <ch...@cxtsoftware.com>
>> wrote:
>> >
>> >> I think there is some terminology confusion at the moment. Rave
>> already has
>> >> (or is adding) the concept of "contexts". For example, "profile",
>> where a
>> >> gadget would process things differently. The REST API now has a
>> /{context}/
>> >> path in it. I'm not an expert so maybe Matt/Erin can clarify how they
>> >> envision that working, then we can contrast that with Stanton's idea
>> and
>> >> come up with the correct terminology.
>> >>
>> >
>> > Contexts, as Sean pointed out allow for Rave to return sets of pages or
>> > templates that relate to an arbitrary grouping and identifier within
>> that
>> > grouping.  For instance, if I am building a library catalog and want to
>> > organize pages in rave by Genre, then I could make a call to
>> > /genre/subgenre and get back pages for the sub genre (or page templates
>> for
>> > genre).
>> >
>> > Same thing goes for different contexts like portal or profile, but in
>> this
>> > case, the context ID is a little more specific /profile/username would
>> get
>> > back profile pages for that user.
>> >
>> > To merge the concepts in this proposal with those in the context
>> proposal,
>> > /profile/username could have a page level context that sets the
>> username in
>> > a JSON object that the widget can read from at render time and thus not
>> > have to use crazy tricks specific to OpenSocial pipelines (which not
>> every
>> > gadget uses) or page level pub/sub.
>>
>> Instead they would all be agreeing on some configuration data format?
>> Ultimately there has to be some buy-in from gadgets that are going to
>> be aware of / consuming the context.
>>
>
> I think the container implementation should publish documentation about
> the structure of the context.  This allows widget developers to point at
> something.
>
>
>>
>> Up to this point, "context" as we have discussed it has been entirely
>> about how we identify pages in a more flexible way. It would still be
>> up to the widgets on this page to decide how they would recognize and
>> consume this context information - there has never been a discussion
>> about feeding them the context.
>>
>
> Overloaded term, but Sean's point is it would be nice to know what Rave
> context you are in from the gadget perspective.  To your point above, maybe
> we define a Rave default JSON schema for context Rave is able to provide.
>  It would be on the widget developers to defensively program against that
> construct.
>
> I am going to put a few issues in and post potential changes as patches so
> everyone can review.
>
>
>>
>> >
>> >
>> >>
>> >> Chris
>> >>
>> >>
>> >> On Wed, Oct 16, 2013 at 5:51 AM, Stanton Sievers <sieverssj@gmail.com
>> >> >wrote:
>> >>
>> >> > Hi Sean,
>> >> >
>> >> > If I understand you correctly I am in agreement on the application
>> >> context
>> >> > portion of this as this sounds similar to, if not the same as, the
>> >> > page-level context that I am describing.  Is that your understanding
>> as
>> >> > well?
>> >> >
>> >> > However, it is not clear to me in this situation how the data gets
>> into
>> >> the
>> >> > pipeline in the first place.  Can you elaborate?  Further, you
>> mention
>> >> the
>> >> > idea of pub/sub being used to configure the gadget, and while I agree
>> >> with
>> >> > this idea on the whole I don't think it solves the same problems I'm
>> >> trying
>> >> > to solve because again, who is sending that configuration and at what
>> >> time
>> >> > must that configuration be set?
>> >> >
>> >> > The gadget and page context ideas I'm proposing try to account for
>> the
>> >> fact
>> >> > that there are two personas of users that could be using an
>> application.
>> >> > The first is the admin who knows about widgets, how to configure
>> them,
>> >> and
>> >> > how they work in general.  The second is an end-user persona who
>> does not
>> >> > know about widgets, how to configure them, or how they work in
>> general.
>> >>  It
>> >> > is this second user that I am trying to enable by allowing the admin
>> user
>> >> > to do all of the configuration ahead of time for the end user to
>> simply
>> >> > consume.
>> >> >
>> >> > Thanks,
>> >> > -Stanton
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Oct 16, 2013 at 8:30 AM, Sean Cooper <se...@apache.org>
>> >> wrote:
>> >> >
>> >> > > If you are talking about gadgets having both an application context
>> >> and a
>> >> > > configuration context, then I want to disagree with adding it.
>> >> > >
>> >> > > I am like the idea of an application context, where a gadget is
>> aware
>> >> of
>> >> > > what application/object it should be displaying data from the
>> container
>> >> > > (e.g. http://server.com/portfolio/356 -> the gadget will have the
>> >> > > portfolio
>> >> > > with the id of 356 in the data pipeline.)  In fact, we are
>> anxiously
>> >> > > waiting for this idea to get into the application.
>> >> > >
>> >> > > I don't like the idea of having an additional layer of
>> configuration
>> >> > > objects.  If your application needs to send in configuration data
>> to
>> >> the
>> >> > > gadget I would recommend including it in the data pipeline or
>> >> performing
>> >> > a
>> >> > > pub/sub call to configure the gadget.  I can't see how we would be
>> able
>> >> > to
>> >> > > easily manage these configuration contexts or configure them in the
>> >> > system.
>> >> > >
>> >> > > -Sean
>> >> > > On Oct 16, 2013 7:21 AM, "Sean Cooper" <se...@apache.org>
>> wrote:
>> >> > >
>> >> > > > This is starting to sound like an application connect.  E.g.
>> >> > > > http://server.com/rave/(applicationName)/(objectId)
>> >> > > >
>> >> > > > Where the page layout is determined by the application's
>> configured
>> >> > > layout
>> >> > > > and the gadgets reference the objectId to retrieve data from the
>> >> > service
>> >> > > > layer.
>> >> > > >
>> >> > > > -Sean
>> >> > > > On Oct 15, 2013 5:32 PM, "Stanton Sievers" <si...@gmail.com>
>> >> > wrote:
>> >> > > >
>> >> > > >> Hi Chris,
>> >> > > >>
>> >> > > >> Here are two examples, one for gadget context and one for page
>> >> > context.
>> >> > > >>
>> >> > > >> For gadget context imagine that in the widget catalog I want the
>> >> > widgets
>> >> > > >> to
>> >> > > >> basically be pre-configured so that an end user can drop them
>> on a
>> >> > page
>> >> > > >> without having to know how widget configuration works.  Imagine
>> a
>> >> > widget
>> >> > > >> that plays YouTube videos and the context it takes is the ID of
>> the
>> >> > > video
>> >> > > >> to play.  As an admin I can define pre-configured widgets in the
>> >> > catalog
>> >> > > >> that a user can drop on a page and not have to configure.  I
>> know
>> >> > > that's a
>> >> > > >> bit contrived, but the point is that the thing in the catalog is
>> >> > > >> pre-configured using the context as the configuration mechanism.
>> >> > > >>
>> >> > > >> For a page context, we have the same pre-configured notion
>> except
>> >> > we're
>> >> > > >> setting some configuration for all gadgets on the page.
>>  Imagine I
>> >> > have
>> >> > > a
>> >> > > >> bunch of gadgets that are location sensitive, e.g., weather,
>> >> traffic,
>> >> > > >> local
>> >> > > >> events, etc... I can make different pages with a different
>> location
>> >> > > >> defined
>> >> > > >> in the context.  So instead of having to configure each
>> individual
>> >> > > widget
>> >> > > >> instance on the page using user preferences, I can set a
>> page-level
>> >> > > >> context
>> >> > > >> location value and just add the widgets to the page.
>> >> > > >>
>> >> > > >> And the context in these cases could just be JSON.  In the first
>> >> > > example,
>> >> > > >> the JSON would have one attribute for the YouTube video ID.
>>  For the
>> >> > > >> second
>> >> > > >> example it would have one attribute for the location.  Things
>> could
>> >> > get
>> >> > > >> more complicated, as you might imagine.
>> >> > > >>
>> >> > > >> Does that help to clarify?
>> >> > > >>
>> >> > > >> Thanks,
>> >> > > >> -Stanton
>> >> > > >>
>> >> > > >>
>> >> > > >> On Tue, Oct 15, 2013 at 5:12 PM, Chris Geer <
>> chris@cxtsoftware.com>
>> >> > > >> wrote:
>> >> > > >>
>> >> > > >> > Stanton,
>> >> > > >> >
>> >> > > >> > Maybe something that would help me is can you describe a
>> concrete
>> >> > > >> example
>> >> > > >> > of your scenarios? That would probably help me understand your
>> >> > > >> perspective.
>> >> > > >> >
>> >> > > >> > Thanks,
>> >> > > >> > Chris
>> >> > > >> >
>> >> > > >> > On Tue, Oct 15, 2013 at 1:59 PM, Stanton Sievers <
>> >> > sieverssj@gmail.com
>> >> > > >> > >wrote:
>> >> > > >> >
>> >> > > >> > > Chris,
>> >> > > >> > >
>> >> > > >> > > We're on similar pages but not quite the same page. :)  Let
>> me
>> >> > > clarify
>> >> > > >> > > inline below.
>> >> > > >> > >
>> >> > > >> > > On Tue, Oct 15, 2013 at 4:23 PM, Chris Geer <
>> >> > chris@cxtsoftware.com>
>> >> > > >> > wrote:
>> >> > > >> > >
>> >> > > >> > > > On Tue, Oct 15, 2013 at 12:55 PM, Stanton Sievers <
>> >> > > >> ssievers@apache.org
>> >> > > >> > > > >wrote:
>> >> > > >> > > >
>> >> > > >> > > > > Hi everyone,
>> >> > > >> > > > >
>> >> > > >> > > > > I would like to propose a series of features to allow
>> >> > arbitrary
>> >> > > >> > > > information
>> >> > > >> > > > > (the context) to be defined for widgets and pages in
>> Rave.
>> >>  At
>> >> > > >> > > > render-time
>> >> > > >> > > > > a widget instance would be given its context in the
>> same way
>> >> > an
>> >> > > >> > > > OpenSocial
>> >> > > >> > > > > gadget using embedded experiences is given a context,
>> and
>> >> most
>> >> > > >> likely
>> >> > > >> > > via
>> >> > > >> > > > > the same mechanism.  The context is arbitrary
>> information
>> >> that
>> >> > > >> could
>> >> > > >> > > take
>> >> > > >> > > > > one of two forms: it could be attached to the widget
>> >> > definition
>> >> > > >> and
>> >> > > >> > all
>> >> > > >> > > > > widget instances would receive that context; or, it
>> could be
>> >> > > >> attached
>> >> > > >> > > to
>> >> > > >> > > > a
>> >> > > >> > > > > page and the page would provide the context to all
>> widget
>> >> > > >> instances
>> >> > > >> > on
>> >> > > >> > > > the
>> >> > > >> > > > > page.  The page context would take precedence over
>> context
>> >> > > >> attached
>> >> > > >> > to
>> >> > > >> > > > the
>> >> > > >> > > > > widget definition in the case of conflict.
>> >> > > >> > > > >
>> >> > > >> > > >
>> >> > > >> > > > Stanton,
>> >> > > >> > > >
>> >> > > >> > > > Overall I like the concept as I think it gives quite a
>> bit of
>> >> > > >> > flexibility
>> >> > > >> > > > we don't have today. I'm wondering if in the OpenSocial
>> world,
>> >> > > >> context
>> >> > > >> > > > could be tied to subviews. For example, since you can have
>> >> > > multiple
>> >> > > >> > > > subviews per surface like HOME.foo and HOME.bar, could
>> context
>> >> > > >> > > > automatically pick a subview if one existed with the same
>> name
>> >> > for
>> >> > > >> > > example?
>> >> > > >> > > > That would be convenient and make logic in a view less
>> >> complex.
>> >> > > >> > > >
>> >> > > >> > >
>> >> > > >> > > The context is not a view-level concept in the gadget.  The
>> >> > context
>> >> > > is
>> >> > > >> > > arbitrary information, such as a JSON object with whatever
>> data
>> >> I
>> >> > > >> want in
>> >> > > >> > > it, very much in the same way that the embedded experiences
>> data
>> >> > > >> model is
>> >> > > >> > > arbitrary JSON or XML data that the gadget knows how to
>> >> interpret.
>> >> > > >>  The
>> >> > > >> > > data would be available to the gadget regardless of the
>> view it
>> >> is
>> >> > > >> > > rendering in.
>> >> > > >> > >
>> >> > > >> > > I may be missing your point, but I'm not sure how subviews
>> would
>> >> > > help
>> >> > > >> to
>> >> > > >> > > achieve this.
>> >> > > >> > >
>> >> > > >> > >
>> >> > > >> > > >
>> >> > > >> > > > >
>> >> > > >> > > > > If everyone thinks this is a good idea, I'd like to
>> take a
>> >> > > staged
>> >> > > >> > > > approach
>> >> > > >> > > > > focusing on OpenSocial first and tackling the following
>> user
>> >> > > >> stories
>> >> > > >> > in
>> >> > > >> > > > > roughly this order:
>> >> > > >> > > > >
>> >> > > >> > > > > 1) Allow the creation of context in the database for a
>> >> widget
>> >> > > and
>> >> > > >> > pass
>> >> > > >> > > > that
>> >> > > >> > > > > context to widget instances
>> >> > > >> > > > > 2) Allow the creation of context in the database for a
>> page
>> >> > and
>> >> > > >> pass
>> >> > > >> > > that
>> >> > > >> > > > > context to widget instances
>> >> > > >> > > > > 3) Allow a Widget to appear multiple times in the
>> catalog
>> >> with
>> >> > > >> > > different
>> >> > > >> > > > > context values
>> >> > > >> > > > >
>> >> > > >> > > >
>> >> > > >> > > > I don't know if I'm a huge fan of this approach as I
>> think it
>> >> > > could
>> >> > > >> > > greatly
>> >> > > >> > > > confuse the widget store. I like the idea of having a
>> context
>> >> > on a
>> >> > > >> page
>> >> > > >> > > > that filters into a widget, but having a context on a
>> widget
>> >> > > doesn't
>> >> > > >> > > quite
>> >> > > >> > > > sit right with me. An alternative approach would be to
>> have a
>> >> > > single
>> >> > > >> > > entry
>> >> > > >> > > > in a store (widget definitions wouldn't have a context
>> >> defined)
>> >> > > and
>> >> > > >> > there
>> >> > > >> > > > could be a way to denote a widget supported multiple
>> contexts.
>> >> > > >> > >
>> >> > > >> > >
>> >> > > >> > > I think that's reasonable.  I'm up for whatever makes the
>> >> > > >> configuration
>> >> > > >> > > easier to understand and use.
>> >> > > >> > >
>> >> > > >> > >
>> >> > > >> > > > When you
>> >> > > >> > > > added a widget to a page, if the page had a context, it
>> would
>> >> > take
>> >> > > >> on
>> >> > > >> > > that
>> >> > > >> > > > context and if the page didn't have a context it would
>> prompt
>> >> > the
>> >> > > >> user
>> >> > > >> > > for
>> >> > > >> > > > what context they would like the widget to take from the
>> list
>> >> of
>> >> > > >> > > supported
>> >> > > >> > > > options.
>> >> > > >> > >
>> >> > > >> > >
>> >> > > >> > > In my mind the page context and gadget-level context aren't
>> >> > mutually
>> >> > > >> > > exclusive.  You should be able to define both.  The page
>> context
>> >> > > >> simply
>> >> > > >> > > takes precedence when there are conflicts.  Although... if
>> the
>> >> > > context
>> >> > > >> > data
>> >> > > >> > > can truly be arbitrary, the container would not be able to
>> do an
>> >> > > >> > > intelligent merge, would it?  Maybe it wouldn't be the end
>> of
>> >> the
>> >> > > >> world
>> >> > > >> > to
>> >> > > >> > > say that the context is always a JSON object so that the
>> >> container
>> >> > > >> could
>> >> > > >> > > merge page-level and gadget-level contexts in some way.
>>  I'll
>> >> have
>> >> > > to
>> >> > > >> > think
>> >> > > >> > > about this some more...
>> >> > > >> > >
>> >> > > >> > >
>> >> > > >> > > > I think the user could also change the context from the
>> >> > > >> > > > preferences screen for each widget on a page (unless it
>> was
>> >> > locked
>> >> > > >> by
>> >> > > >> > the
>> >> > > >> > > > page context).
>> >> > > >> > > >
>> >> > > >> > > >
>> >> > > >> > > I don't think we would want the context to be able to be
>> changed
>> >> > in
>> >> > > >> the
>> >> > > >> > > preferences screen for the gadget.  The preferences screen
>> sets
>> >> > > values
>> >> > > >> > on a
>> >> > > >> > > per widget-instance basis.  The context applies for all
>> >> instances
>> >> > > of a
>> >> > > >> > > given widget on the page.  If you want to differentiate your
>> >> > widget
>> >> > > >> > > instances, you can define a different context or change user
>> >> > > >> preferences.
>> >> > > >> > >
>> >> > > >> > >
>> >> > > >> > > >
>> >> > > >> > > > > 4) Allow the configuration of context in the admin UI
>> for a
>> >> > > widget
>> >> > > >> > > > > 5) Allow the configuration of context in the admin UI
>> for a
>> >> > page
>> >> > > >> > > > >
>> >> > > >> > > > > There are probably other features that could grow out of
>> >> this
>> >> > > >> > proposal,
>> >> > > >> > > > but
>> >> > > >> > > > > this is the scope I'm focused on now.
>> >> > > >> > > > >
>> >> > > >> > > >
>> >> > > >> > > > To give a concrete example of what's in my head...
>> >> > > >> > > >
>> >> > > >> > > > User Widget
>> >> > > >> > > >  - User Context
>> >> > > >> > > >  - Manager Context
>> >> > > >> > > >  - Admin Context
>> >> > > >> > > >
>> >> > > >> > > > Each context would provide a different view and different
>> >> > > >> functionality
>> >> > > >> > > > based on that context. User Context would be a profile
>> view
>> >> for
>> >> > > >> example
>> >> > > >> > > > which Admin Context would list all users and provide admin
>> >> > > >> functions.
>> >> > > >> > > > Something brings up is security, it would be nice to tie
>> >> > contexts
>> >> > > to
>> >> > > >> > > > roles/groups so that only certain users and select certain
>> >> > > >> contexts. I
>> >> > > >> > > > realize we don't have a group/role security model at the
>> >> moment
>> >> > > but
>> >> > > >> > it's
>> >> > > >> > > > something we need to look at.
>> >> > > >> > > >
>> >> > > >> > > >
>> >> > > >> > > Given what I said above about context not being tied to
>> views
>> >> and
>> >> > > >> > subviews,
>> >> > > >> > > does this still make sense?
>> >> > > >> > >
>> >> > > >> > >
>> >> > > >> > > > Is this even close to how you viewed contexts or am I
>> looking
>> >> at
>> >> > > >> this
>> >> > > >> > the
>> >> > > >> > > > wrong way?
>> >> > > >> > > >
>> >> > > >> > > > Thanks,
>> >> > > >> > > > Chris
>> >> > > >> > > >
>> >> > > >> > > > >
>> >> > > >> > > > > Let me know if you have any questions.
>> >> > > >> > > > >
>> >> > > >> > > > > Thanks!
>> >> > > >> > > > > -Stanton
>> >> > > >> > > > >
>> >> > > >> > > >
>> >> > > >> > >
>> >> > > >> >
>> >> > > >>
>> >> > > >
>> >> > >
>> >> >
>> >>
>>
>
>