I agree with all of your points below with one small clarification -- If my gaget calls the raw gadgets.rpc methods it can interact with the container.
In any case moving a module into a Require block also: 1) provides a form of URN for script resources. This can help avoid multiple inclusion and loads the resource once and only once. 2) Allows 3rd party library to participate as a transitive dependency. Suppose I wanted to make the tabs module very fancy, I could add jquery-ui as a dependency and it would just work. 3) Potentially providing namespacing. Right now we have contention for $ etal. It would be beneficial to map each 'Require' to it's namespace ala goog.require() FB.require() etc. We're pretty close with this already, core.* maps almost 1:1 with gadgets.* My original use-case for doing this was prototyping a new container framework to replace gadgets.js. To make life easy I wanted to use jQuery (see #2 above). I also wanted to include a single script tag on the page. Thus moving jQuery into a feature. 2010/5/13 ๏̯͡๏ Jasvir Nagra <jas...@google.com> > The html parser already parses script tags and so knows the urls of code > being included. At this point, the rewriter could substitute a > known-to-cajole version if it cared to and/or inline the script. Is your > concern that a library like jQuery may have been modified and/or be > included > from an unrecognized url and so not be recognized as jQuery? I don't > really have a problem with the change you're suggesting - I'd just like to > clarify the the purpose of the <Require> tag. > > There are two ways in which <Require> tags are being used currently - as a > powerbox to expose new functionality from the container to a gadget that > could not be expressed by the apis that the gadget already has access to; > and as a convenient alternative to <script> tags that point to a well-known > library of functions. An example of the former is dynamic-height - a > gadget > cannot resize itself without help from the container; and an example of the > latter is minimessage - it provides a convenient api to do things which the > gadget has sufficient authority to do already. > > The nice thing about allowing the use of the Require tag for both of these > is: > * the flexibility of varying its semantics from script tags (in particular > the mapping from the identifier "org.jquery.core-1.4.2" to actual code > which > may a modified jquery core). > * the declarative syntax also makes it slightly easier for a container to > know what libraries gadgets are using > * once gadgets start using the Require to request libraries, the container > can choose whether to provide a library via taming or cajoling. > > The downside is subtle and probably not a real downside. By conflating the > semantics of Require to provide both a powerbox and convenience apis, > containers that choose not to grant a convenience api aren't actually > depriving a gadget of any power at all since the gadget can include the > same > API via script inclusion. > > On Thu, May 13, 2010 at 5:20 PM, Paul Lindner <plind...@linkedin.com> > wrote: > > > we could offer caja versions of said libraries, plus the js can be > concat'd > > with the rest of the payload. Lots of interesting things can fallout > from > > this technique. > > > > 2010/5/13 ๏̯͡๏ Jasvir Nagra <jas...@google.com> > > > > > On Thu, May 13, 2010 at 5:07 PM, Paul Lindner <lind...@inuus.com> > wrote: > > > > > > > There are some features that are new, experimental and generally not > > > > production ready nor standardized yet. However I'd like to see them > > > > checked > > > > in and maintained over time after such time they can graduate to > > > > shindig-gadgets and/or shindig-social-api. > > > > > > > > I propose putting these new features in a new package named > > > shindig-extras. > > > > Code will be checked into java/extras and it will support javascript > > > > features and java extensions via Guice multibindings and overrides. > > > > > > > > The features I want to move here are: > > > > > > > > * javascript features for popular javascript libraries. For example > > > here's > > > > org.jquery.core-1.4.2/feature.xml > > > > > > > > > > Why would something like jQuery be a feature requested by a gadget > rather > > > than a script the gadget author includes with a script tag? > > > > > > > > > > > > > > <feature> > > > > <name>org.jquery.core-1.4.2</name> > > > > <gadget> > > > > <script src=" > > > > http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"/> > > > > </gadget> > > > > <container> > > > > <script inline="true" src=" > > > > http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"/> > > > > </container> > > > > </feature> > > > > > > > > > > > > * New Api handlers for "Tokens" and "Apps" -- these will provide a > way > > to > > > > create containers that run on third party web sites. > > > > > > > > * Anything else anyone else wants to contribute. > > > > > > > > > >
