If you are talking about gadgets having both an application context and a configuration context, then I want to disagree with adding it.
I am like the idea of an application context, where a gadget is aware of what application/object it should be displaying data from the container (e.g. http://server.com/portfolio/356 -> the gadget will have the portfolio with the id of 356 in the data pipeline.) In fact, we are anxiously waiting for this idea to get into the application. I don't like the idea of having an additional layer of configuration objects. If your application needs to send in configuration data to the gadget I would recommend including it in the data pipeline or performing a pub/sub call to configure the gadget. I can't see how we would be able to easily manage these configuration contexts or configure them in the system. -Sean On Oct 16, 2013 7:21 AM, "Sean Cooper" <[email protected]> wrote: > 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 >> > > > > >> > > > >> > > >> > >> >
