On Wed, Oct 16, 2013 at 12:53 PM, Matt Franklin <[email protected]> wrote: > On Wed, Oct 16, 2013 at 2:31 PM, Chris Geer <[email protected]> wrote: > >> 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. >> > > Contexts, as Sean pointed out allow for Rave to return sets of pages or > templates that relate to an arbitrary grouping and identifier within that > grouping. For instance, if I am building a library catalog and want to > organize pages in rave by Genre, then I could make a call to > /genre/subgenre and get back pages for the sub genre (or page templates for > genre). > > Same thing goes for different contexts like portal or profile, but in this > case, the context ID is a little more specific /profile/username would get > back profile pages for that user. > > To merge the concepts in this proposal with those in the context proposal, > /profile/username could have a page level context that sets the username in > a JSON object that the widget can read from at render time and thus not > have to use crazy tricks specific to OpenSocial pipelines (which not every > gadget uses) or page level pub/sub.
Instead they would all be agreeing on some configuration data format? Ultimately there has to be some buy-in from gadgets that are going to be aware of / consuming the context. Up to this point, "context" as we have discussed it has been entirely about how we identify pages in a more flexible way. It would still be up to the widgets on this page to decide how they would recognize and consume this context information - there has never been a discussion about feeding them the context. > > >> >> 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 >> > > >> > > > > >> > > >> > > > >> > > >> > > >> > > >> > >> > > >> >> > > > >> > > >> > >>
