Hi Ben,
As per the samplecontiner code
function generateGadgets(metadata) {
// TODO: The gadget.js file should really have a clearGadgets method
gadgets.container.gadgets_ = {};
for (var i = 0; i < metadata.gadgets.length; i++) {
gadget = gadgets.container.createGadget(
{'specUrl': metadata.gadgets[i].url, 'title':
metadata.gadgets[i].title});
gadget.setServerBase('../../');
gadget.secureToken = escape(generateSecureToken());
gadgets.container.addGadget(gadget);
}
gadgets.container.layoutManager.setGadgetChromeIds(['gadget-chrome']);
reloadStateFile(function() {
gadgets.container.renderGadgets();
});
};
I think what they have done is something like Tamlyn Rhodes has suggested in
this thread
var gadgetDefaultPrefs = {};
for (var prefName in gadgetMetadata.userPrefs) {
gadgetDefaultPrefs[prefName] =
gadgetMetadata.userPrefs[prefName].default;
}
var gadget = gadgets.container.getGadget(gadgetId);
gadget.setUserPrefs(gadgetDefaultPrefs);
gadget.refresh();
Java Shindig is supporting JsonRpc and so gadget/metadata call. That's why
its working properly in Java Shindig and PHP side its still not supported
and hence its not working with PHP Shindig (even sample container it self
not working with PHP Shindig).
Anybody please correct me if I am wrong :)
2008/9/18 ben bonfil <[EMAIL PROTECTED]>
> To all involved in this thread,
> Can you conclude on the preferred way to do this? I have just ran into a
> problem with my solution ( created a bug report actually, though I guess
> it's not really valid - https://issues.apache.org/jira/browse/SHINDIG-613)
>
> Before I go ahead and fix it, I'd like to know what is the correct way to
> initialize the userprefs, and whether it was already patched in the latest
> revision (didn't see anything related to it on the SVN log)
>
> Thanks,
>
> Ben
>
> 2008/9/14 ben bonfil <[EMAIL PROTECTED]>
>
> > Hi,
> > I've attached the patch for the method that I use.
> >
> > Ben
> >
> >
> > 2008/9/12 John Hjelmstad <[EMAIL PROTECTED]>
> >
> >> That's fair. So long as prefs.js doesn't parse the URL but instead
> accepts
> >> only the prefs values the server provides, we're golden.
> >>
> >> 2008/9/12 Kevin Brown <[EMAIL PROTECTED]>
> >>
> >> > 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.
> >> > > > > >> > > >
> >> > > > > >> > >
> >> > > > > >> >
> >> > > > > >>
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
