+cc Ben Bonfil, who asked a similar question on a separate thread.
I should note that this proposed solution does discourage "proper" IFRAME
URL generation, whether by PHP or Java code, which provides default UserPref
values in addition to other benefits (eg. consistent handling of
query keys). As such, I'm cool on it. Thoughts?
Compelling reasons server-side IFRAME generation
is more burdensome than the benefits?
--John
On 9/11/08, John Hjelmstad <[EMAIL PROTECTED]> wrote:
>
> Given that default values for a given gadget fixed in the spec, I think the
> cleaner solution is to inject some kind of defaultPrefs object into the
> gadget when rendering it, somewhat like gadgets.config.init() does.
>
> As implemented today (which admittedly isn't the cleanest impl, but that's
> an orthogonal problem), that would mean modifying GadgetRenderingTask to do
> something like:
>
> js.append("gadgets.Prefs.setDefaults(").append(jsonObjectRepresentingDefaultsOf(gadget.getSpec()).append(");\n");
>
> ...then augmenting features/core/prefs.js correspondingly to initialize
> from defaults when the up_<key> equivalent isn't available.
>
> --John
>
> On 9/10/08, Cassie <[EMAIL PROTECTED]> wrote:
>>
>> (in case you are interested - don't feel pressured though :)
>>
>> samplecontainer.js actually already makes calls to the metadata servlet.
>> see
>> line 167 - the "requestGadgetMetaData" function. This came from a
>> different
>> patch which gave the samplecontainer the ability to show gadget titles.
>>
>> - Caszsie
>>
>>
>>
>> On Wed, Sep 10, 2008 at 6:48 AM, Tamlyn Rhodes <[EMAIL PROTECTED]> wrote:
>>
>> > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <[EMAIL PROTECTED]> wrote:
>> > > Hey Tamlyn - do you think you could make this into a patch and attach
>> it
>> > to
>> > > a jira issue for Shindig?
>> >
>> > The thing is I've done it from outside of gadgets.js so it's not
>> > really patchable. Doing it in gadgets.js would mean making an ajax
>> > call to fetch the metadata in the gadgets.container.addGadget method
>> > and I'm not really sure how that would work since gadgets.io isn't
>> > available in the container (unless i've misunderstood).
>> >
>> > I'm aware that you're keen to maintain clear separation between
>> > Shindig and the JavaScript code that manages the layout/chrome but for
>> > most people actually using Shindig I suspect this separation is rather
>> > more theoretical than practical. I've been developing a drag & drop
>> > layout/framework using jQuery, PHP and MySQL and I hope to open source
>> > this once I get it working. This should be some time in September.
>> >
>> > Tamlyn.
>> >
>>
>
>
