2008/7/28 Cassie <[EMAIL PROTECTED]> > Well I think it depends on who gets to make the cajoled vs non-cajoled > decision. Long term my thinking was that gadget authors won't get to choose. > Probably 99% of them will be cajoled and some certain white listed or > special gadgets will stay non-cajoled if the container wants them to. > Because the container decides then the url is the best place for the switch. > > > On the other hand, if the gadget developer gets to choose whether or not > they are cajoled then the logic should be turned on by a require tag. Short > term maybe this makes more sense... so that the developers can test it out > in live containers? Or - you could say that they can already test cajoling > out in shindig... so maybe they don't need control. > > Anyway, so I was basically thinking that - container choice = url and > gadget choice = require. > So, who gets the power? :) >
Ok, so a gadget should be cajoled if the container mandates it, or the gadget requests it? Right now, the meaning seems to be url=1 -> this iframe needs to have the caja runtime JS loaded <require feature-caja> -> the gadget source requires cajoling > > - Cassie > > > > On Mon, Jul 28, 2008 at 12:29 PM, Mike Samuel <[EMAIL PROTECTED]>wrote: > >> So in an environment that wants to serve both cajoled and uncajoled >> gadgets from the same gadget-server, the caja=1 switch is going to be what >> distinguishes the two long term? >> >> 2008/7/28 Cassie <[EMAIL PROTECTED]> >> >> btw - if we are confident, or if you just want to try out only needing the >>> caja=1 in the url, then the opensocial-current/feature.xml line 23 just >>> needs to be commented in. Then gadgets don't need the require. >>> >>> >>> On Mon, Jul 28, 2008 at 11:52 AM, Cassie <[EMAIL PROTECTED]> wrote: >>> >>>> If we were completely confident in caja then the require feature >>>> wouldn't be needed. caja would be included and turned on all of the time. >>>> When caja=0 the gadget would not be cajoled and so caja shouldn't have any >>>> affect. If caja=1 then the gadget would be cajoled and caja would do all >>>> its >>>> magic goodness. >>>> >>>> So... are we confident that caja is ready to handle both cajoled and >>>> non-cajoled gadgets without causing any issues? >>>> >>>> - Cassie >>>> >>>> >>>> >>>> On Mon, Jul 28, 2008 at 11:04 AM, Mike Samuel <[EMAIL PROTECTED]>wrote: >>>> >>>>> Shindiggers, >>>>> >>>>> There are two gates a gadget has to pass through to get cajoled right >>>>> now. >>>>> (1) The enableCaja bit specified via ?caja=1 in the URL which adds the >>>>> CajaContentRewriter to the rewriter chain. >>>>> (2) The <Require feature="caja"> specified in the gadget spec which >>>>> causes caja.js and friends to be loaded. >>>>> >>>>> There doesn't seem to be any case where (1) should be different from >>>>> (2). Can we get rid of the need for both? >>>>> >>>>> I don't see an easy way for the content rewriter to be conditionally >>>>> added based on the presence of a <Require> >>>>> element, since that decision seems to be made before the gadget spec >>>>> is parsed, but I don't know the code that well. Any ideas? >>>>> >>>>> cheers, >>>>> mike >>>>> >>>> >>>> >>> >> >
