> On 2011-08-25 15:32:47, Henry Saputra wrote: > > http://svn.apache.org/repos/asf/shindig/trunk/config/container.js, line 160 > > <https://reviews.apache.org/r/1657/diff/2/?file=35523#file35523line160> > > > > I dont think we need to add alias for "default" view to other default > > view names. The gadget.xml could contain <Content> with no "view" property > > which will be set as "default" in Shindig. > > > > When metadata request come, it will contain "default" view as one of > > the supported views and it depends on controller in the container to render > > the gadget with the right view. > > > > The only aliases we could set for default view is probably empty string > > so container could render gadget in default view, which is <Content> block > > without view property. > > Ryan Baxter wrote: > Henry this kind of stems from the conversation I started on the spec > list. There is a disconnect here between the spec and the implementation. > There is no concept of the default view in the spec. The spec never calls > out what content section is called which has no view. In Shindig assumes > this is something called the default view. However the spec also does not > state that every gadget needs to implement the default view. However if the > container does not specify the view to render and the gadget does not have a > default view, than the container fails to render the gadget. In my eyes this > is not right. One way to fix this, is to alias the default view to any other > view. That way if the gadget does not have a default view, ie a content > section with no view, than we can render something. > > I guess the bottom line is something needs to change. I would like to > resolve it at a spec level, so all 2.NEXT gadgets and containers will not > have this problem. However I would also like to come up with a solution for > 2.0 and 2.NEXT containers can support gadgets developed against prior specs > as well. > > Stanton Sievers wrote: > Henry, I can certainly remove the default view configuration from > container.js, but I think it's provides better out-of-the-box behavior from > Shindig if it's there. The common container example page tries to render > gadgets to their default views and many popular gadgets that are provided in > Shindig examples, e.g., http://www.labpixies.com/campaigns/todo/todo.xml, > don't provide a "default" view or a <Content> block with no view. These fail > to load with the out-of-the-box samples in Shindig. By providing the default > view configuration in container.js along with the other changes in this > patch, these examples will work. > > If people don't want this configuration in their own deployments they can > remove it.
Ah ok, so the alias for default is targeted for gadget with no <Content> block with no view property. Thanks for the explanation. +1 - Henry ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1657/#review1643 ----------------------------------------------------------- On 2011-08-26 11:22:35, Stanton Sievers wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/1657/ > ----------------------------------------------------------- > > (Updated 2011-08-26 11:22:35) > > > Review request for shindig and Ryan Baxter. > > > Summary > ------- > > osapi.container.GadgetSite.prototype.render fails to render a gadget using a > given view when that gadget does not explicitly define that view, even in the > case where the container configuration has aliases for that view. > > For instance, Gadget A supports the "profile" and "canvas" views only. The > container configuration defines the "home" view and provides "profile" as an > alias for "home". In the use case where the container tries to render Gadget > A using the "home" view, gadget render will fail, even though the gadget > supports "profile" and it has been specified as an alias for "home" in the > container configuration. > > This problem commonly manifests itself in Shindig because of the way > "default" views are handled. By default, Shindig will attempt to render the > gadget using the "default" view. If the gadget does not support that view, > rendering will fail. > > > This addresses bug SHINDIG-1596. > https://issues.apache.org/jira/browse/SHINDIG-1596 > > > Diffs > ----- > > http://svn.apache.org/repos/asf/shindig/trunk/config/container.js 1160327 > > http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.gadget/gadget_site.js > 1160327 > > Diff: https://reviews.apache.org/r/1657/diff > > > Testing > ------- > > Tested rendering a gadget in the "default" view case where the gadget doesn't > support default. > > > Thanks, > > Stanton > >
