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