On Wed, Oct 16, 2013 at 2:31 PM, Chris Geer <[email protected]> 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.
>
> Chris
>
>
> On Wed, Oct 16, 2013 at 5:51 AM, Stanton Sievers <[email protected]
> >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 <[email protected]>
> 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" <[email protected]> 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" <[email protected]>
> > 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 <[email protected]>
> > > >> 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 <
> > [email protected]
> > > >> > >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 <
> > [email protected]>
> > > >> > wrote:
> > > >> > >
> > > >> > > > On Tue, Oct 15, 2013 at 12:55 PM, Stanton Sievers <
> > > >> [email protected]
> > > >> > > > >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
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>
