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.
> > > >
> > >
> >
>
