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