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