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