That's not a complete solution because it skips user pref substitution. The
only thing that completely allows skipping filling in the user pref defaults
in the url is to make the user prefs merge happen server side.
2008/9/11 ben bonfil <[EMAIL PROTECTED]>
> 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.ioisn'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.
> >> > > >
> >> > >
> >> >
> >>
> >
>
