To make sure we all think this is the right path, I created a patch that demonstrates a page level property bag. This bag can then be injected by the to-be-written JS code into the widgets.
https://reviews.apache.org/r/15207 If no one has any issues, I will commit the above patch to trunk. On Thu, Oct 31, 2013 at 5:26 PM, Matt Franklin <[email protected]>wrote: > On Mon, Oct 28, 2013 at 1:14 AM, Erin Noe-Payne > <[email protected]>wrote: > >> 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. >> > > I think the container implementation should publish documentation about > the structure of the context. This allows widget developers to point at > something. > > >> >> 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. >> > > Overloaded term, but Sean's point is it would be nice to know what Rave > context you are in from the gadget perspective. To your point above, maybe > we define a Rave default JSON schema for context Rave is able to provide. > It would be on the widget developers to defensively program against that > construct. > > I am going to put a few issues in and post potential changes as patches so > everyone can review. > > >> >> > >> > >> >> >> >> 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 >> >> > > >> > > > > >> >> > > >> > > > >> >> > > >> > > >> >> > > >> > >> >> > > >> >> >> > > > >> >> > > >> >> > >> >> >> > >
