2008/9/12 John Hjelmstad <[EMAIL PROTECTED]>
> I could be misunderstanding, but it sounds like that's what Ben did -- pass
> (in the server) the defaults to setMessages_ with some special format, and
> have prefs.js read them when no up_<key> values are provided on the URL.
> Meanwhile, UP substitution is already handled by the server, with a merge
> algorithm that presumably mirrors what Ben's does in JS.
Yeah, and I think that's error prone. We should be doing the merging in just
one place, or we're going to have bugs.
>
>
> -John
>
> 2008/9/12 Kevin Brown <[EMAIL PROTECTED]>
>
> > 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.
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>
