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