I think there is some terminology confusion at the moment. Rave already has
(or is adding) the concept of "contexts". For example, "profile", where a
gadget would process things differently. The REST API now has a /{context}/
path in it. I'm not an expert so maybe Matt/Erin can clarify how they
envision that working, then we can contrast that with Stanton's idea and
come up with the correct terminology.Chris On Wed, Oct 16, 2013 at 5:51 AM, Stanton Sievers <[email protected]>wrote: > Hi Sean, > > If I understand you correctly I am in agreement on the application context > portion of this as this sounds similar to, if not the same as, the > page-level context that I am describing. Is that your understanding as > well? > > However, it is not clear to me in this situation how the data gets into the > pipeline in the first place. Can you elaborate? Further, you mention the > idea of pub/sub being used to configure the gadget, and while I agree with > this idea on the whole I don't think it solves the same problems I'm trying > to solve because again, who is sending that configuration and at what time > must that configuration be set? > > The gadget and page context ideas I'm proposing try to account for the fact > that there are two personas of users that could be using an application. > The first is the admin who knows about widgets, how to configure them, and > how they work in general. The second is an end-user persona who does not > know about widgets, how to configure them, or how they work in general. It > is this second user that I am trying to enable by allowing the admin user > to do all of the configuration ahead of time for the end user to simply > consume. > > Thanks, > -Stanton > > > > On Wed, Oct 16, 2013 at 8:30 AM, Sean Cooper <[email protected]> wrote: > > > 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 > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > > > >
