On Mon, Oct 28, 2013 at 1:14 AM, Erin Noe-Payne <[email protected]>wrote:
> On Wed, Oct 16, 2013 at 12:53 PM, Matt Franklin > <[email protected]> wrote: > > 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. > > 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 <[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 > >> > > >> > > > > > >> > > >> > > > > >> > > >> > > > >> > > >> > > >> > > >> > >> > > > > >> > > > >> > > >> >
