My solution was indeed to pass the default values in the setMessages_
array(like iGoogle), and modify prefs.js accordingly.
Ben Bonfil
On 9/12/08, John Hjelmstad <[EMAIL PROTECTED]> wrote:
> Correct me if I'm wrong, but the only server-side code that touches
> gadgets.Prefs initializes it with Messages (setMessages_), not Prefs at all,
> all of which are initialized by parsing gadgets.util.getUrlParameters().
>
> I don't have any strong opinion on implementation particulars - either way
> server-side code spits out defaults and some corresponding JS reads them...
> assuming we want to support this in the first place.
>
> -John
>
> On 9/11/08, Kevin Brown <[EMAIL PROTECTED]> wrote:
>>
>> That's wholly unnecessary. If we want gadgets.Prefs to include defaults,
>> we
>> just need to make the server side code that outputs gadgets.Prefs properly
>> merge in the defaults from the spec. There's no reason to add new client
>> libraries.
>>
>>
>> On Thu, Sep 11, 2008 at 3:01 PM, 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.
>> > > >
>> > >
>> >
>>
>
