While I don't agree with the trust assumptions being made in the
corporate environment, a few points of feedback in making this
proposal align with existing features.
- Why change spec on <modulePrefs to use @renderTypesSupported, rather
the just have gadgets request the <require feature="inline"> like caja
does?
- Glad to see you are considering the name space conflicts that are
inherent in this model. Suggest the scope feature not be labeled
"context" as this term is already way overloaded in open social. I
would be more specific in <require feature="inline-scope" or just use
the same feature as above to indicate the gadget requires inline
support <require feature="inline"
-Will the inline feature do any validation for either option A or B to
make sure your scoping semantics are followed, since this is really
requiring the gadget developer to code in the namespace isolation,
versus caja providing the namespace isolation automatically?
-I think one of your main motivations for this inlining proposal is
wanting to support use of dojo in the gadget implementation, which is
not compatible with cajoling? Might be worth adding the to the
proposal.
--Andrew
> --
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to
> opensocial-an...@googlegroups.com.
> To unsubscribe from this group, send email to
> opensocial-and-gadg...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>
Grace,
While I don't agree with the trust assumptions being made in the
corporate environment, a few points of feedback in making this
proposal align with existing features.
- Why change spec on <modulePrefs to use @renderTypesSupported, rather
the just have gadgets request the <require feature="inline"> like caja
does?
Actually we considered this way and also have the implementation. But further thought, we need the gadget developer to indicate whether or not the gadget supports being inlined ... this allows gadgets to be removed from consideration for being inlined, but by itself will never cause a gadget to be inlined. We need site/page administers to indicate whether or not a specific instance of a gadget which supports being inlined will actually be inlined. If using this require way, the inline related features will be loaded, but if the gadget can't be inlined, it is not necessary. So we introduce @renderTypesSupported which indicates whether the gadget can be inlined; the reference placing the gadget in the page can indicate whether or not to inline it by passing a renderParameter named renderType, such as : myContainer.navigateGadget(gadgetSite0, gadgetUrls[0], {view:'profile'}, {height:300,renderType:'inline'}); the whole page can indicate whether or not to inline the whole page's gadgets by pass a parameter named renderType, such as :
- Glad to see you are considering the name space conflicts that are
inherent in this model. Suggest the scope feature not be labeled
"context" as this term is already way overloaded in open social. I
would be more specific in <require feature="inline-scope" or just use
the same feature as above to indicate the gadget requires inline
support <require feature="inline"
-Will the inline feature do any validation for either option A or B to
make sure your scoping semantics are followed, since this is really
requiring the gadget developer to code in the namespace isolation,
versus caja providing the namespace isolation automatically?
-I think one of your main motivations for this inlining proposal is
wanting to support use of dojo in the gadget implementation, which is
not compatible with cajoling? Might be worth adding the to the
proposal.