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