You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Tamlyn Rhodes <ta...@tamlyn.org> on 2008/09/01 16:05:15 UTC
default_value not working
None of my gadgets are respecting the <UserPrefs default_value=""> attribute.
I've copied the sample gadget spec from
http://code.google.com/apis/gadgets/docs/fundamentals.html#SetPrefs
and loaded it into my shindig container. The 'Count' and 'Reset'
buttons work fine but always start counting from 0, regardless of the
value I give for default_value in the modified gadget spec.
Do I need to explicitly set all the default values at runtime based on
the results of a call to /gadgets/metadata?
T.
Re: default_value not working
Posted by John Hjelmstad <fa...@google.com>.
+cc Ben Bonfil, who asked a similar question on a separate thread.
I should note that this proposed solution does discourage "proper" IFRAME
URL generation, whether by PHP or Java code, which provides default UserPref
values in addition to other benefits (eg. consistent handling of
query keys). As such, I'm cool on it. Thoughts?
Compelling reasons server-side IFRAME generation
is more burdensome than the benefits?
--John
On 9/11/08, John Hjelmstad <fa...@google.com> 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 <do...@apache.org> 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 <ta...@tamlyn.org> wrote:
>>
>> > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <do...@apache.org> 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.
>> >
>>
>
>
Re: default_value not working
Posted by John Hjelmstad <fa...@google.com>.
Care to post a patch?
2008/9/11 ben bonfil <bo...@gmail.com>
> 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 <fa...@google.com> 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 <et...@google.com> 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 <fa...@google.com>
> 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 <do...@apache.org> 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 <ta...@tamlyn.org>
> >> > wrote:
> >> > >
> >> > > > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <do...@apache.org> 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.
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: default_value not working
Posted by John Hjelmstad <fa...@google.com>.
SGTM, code 75% written. Patch soon, applied to SHINDIG-175.
2008/10/15 Kevin Brown <et...@google.com>
> 2008/10/15 John Hjelmstad <fa...@google.com>
>
> > Resuscitating this thread, as I'd like to post a patch.
> > While I understand that it's error-prone to merge in two places, I'm not
> > sure we have a choice here. Prefs passed on the fragment are by
> definition
> > not available to the server, so can't participate in a server-side merge.
> > Passing all prefs on the query string obviously kills caching. I see two
> > options:
> >
> > 1. We could require that anybody who generates rendering URLs manually
> put
> > all userprefs on the query string. This allows all prefs merging to
> happen
> > in-server, but is inconsistent with prefs on the fragment. That in turn
> has
> > client implications, since a container "properly" rendering a gadget
> would
> > have to include all userprefs at all times in its URL (pre-merged). True,
> > that happens with the Java impl today, but it's another somewhat painful
> > burden. Also, implementation of this mechanism will still need
> temporarily
> > to have JS and server-merges, since the JS is shared.
> > 2. Deal with two merges, which is inevitable for a time anyway.
>
>
> All you need to do is make RenderingContentRewriter add the calls to set
> the
> prefs. The client code may wind up doing an overwrite, but that's
> acceptable.
>
>
> >
> > I'll implement the first piece of this (server merge and output, in Java)
> > and visit the remainder thereafter.
> >
> > John
> >
> > 2008/9/12 John Hjelmstad <fa...@google.com>
> >
> > > 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 <et...@google.com>
> > >
> > >> 2008/9/12 John Hjelmstad <fa...@google.com>
> > >>
> > >> > 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 <et...@google.com>
> > >> >
> > >> > > 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 <bo...@gmail.com>
> > >> > >
> > >> > > > 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 <fa...@google.com> 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 <et...@google.com> 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 <
> > >> fargo@google.com>
> > >> > > > 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 <do...@apache.org> 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 <
> > >> > tamlyn@tamlyn.org
> > >> > > >
> > >> > > > >> > wrote:
> > >> > > > >> > >
> > >> > > > >> > > > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <
> doll@apache.org>
> > >> > 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.
> > >> > > > >> > > >
> > >> > > > >> > >
> > >> > > > >> >
> > >> > > > >>
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: default_value not working
Posted by Kevin Brown <et...@google.com>.
2008/10/15 John Hjelmstad <fa...@google.com>
> Resuscitating this thread, as I'd like to post a patch.
> While I understand that it's error-prone to merge in two places, I'm not
> sure we have a choice here. Prefs passed on the fragment are by definition
> not available to the server, so can't participate in a server-side merge.
> Passing all prefs on the query string obviously kills caching. I see two
> options:
>
> 1. We could require that anybody who generates rendering URLs manually put
> all userprefs on the query string. This allows all prefs merging to happen
> in-server, but is inconsistent with prefs on the fragment. That in turn has
> client implications, since a container "properly" rendering a gadget would
> have to include all userprefs at all times in its URL (pre-merged). True,
> that happens with the Java impl today, but it's another somewhat painful
> burden. Also, implementation of this mechanism will still need temporarily
> to have JS and server-merges, since the JS is shared.
> 2. Deal with two merges, which is inevitable for a time anyway.
All you need to do is make RenderingContentRewriter add the calls to set the
prefs. The client code may wind up doing an overwrite, but that's
acceptable.
>
> I'll implement the first piece of this (server merge and output, in Java)
> and visit the remainder thereafter.
>
> John
>
> 2008/9/12 John Hjelmstad <fa...@google.com>
>
> > 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 <et...@google.com>
> >
> >> 2008/9/12 John Hjelmstad <fa...@google.com>
> >>
> >> > 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 <et...@google.com>
> >> >
> >> > > 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 <bo...@gmail.com>
> >> > >
> >> > > > 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 <fa...@google.com> 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 <et...@google.com> 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 <
> >> fargo@google.com>
> >> > > > 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 <do...@apache.org> 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 <
> >> > tamlyn@tamlyn.org
> >> > > >
> >> > > > >> > wrote:
> >> > > > >> > >
> >> > > > >> > > > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <do...@apache.org>
> >> > 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.
> >> > > > >> > > >
> >> > > > >> > >
> >> > > > >> >
> >> > > > >>
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: default_value not working
Posted by John Hjelmstad <fa...@google.com>.
Resuscitating this thread, as I'd like to post a patch.
While I understand that it's error-prone to merge in two places, I'm not
sure we have a choice here. Prefs passed on the fragment are by definition
not available to the server, so can't participate in a server-side merge.
Passing all prefs on the query string obviously kills caching. I see two
options:
1. We could require that anybody who generates rendering URLs manually put
all userprefs on the query string. This allows all prefs merging to happen
in-server, but is inconsistent with prefs on the fragment. That in turn has
client implications, since a container "properly" rendering a gadget would
have to include all userprefs at all times in its URL (pre-merged). True,
that happens with the Java impl today, but it's another somewhat painful
burden. Also, implementation of this mechanism will still need temporarily
to have JS and server-merges, since the JS is shared.
2. Deal with two merges, which is inevitable for a time anyway.
I'll implement the first piece of this (server merge and output, in Java)
and visit the remainder thereafter.
John
2008/9/12 John Hjelmstad <fa...@google.com>
> 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 <et...@google.com>
>
>> 2008/9/12 John Hjelmstad <fa...@google.com>
>>
>> > 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 <et...@google.com>
>> >
>> > > 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 <bo...@gmail.com>
>> > >
>> > > > 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 <fa...@google.com> 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 <et...@google.com> 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 <
>> fargo@google.com>
>> > > > 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 <do...@apache.org> 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 <
>> > tamlyn@tamlyn.org
>> > > >
>> > > > >> > wrote:
>> > > > >> > >
>> > > > >> > > > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <do...@apache.org>
>> > 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.
>> > > > >> > > >
>> > > > >> > >
>> > > > >> >
>> > > > >>
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: default_value not working
Posted by Astha Bhatnagar <as...@gmail.com>.
there I got the hint :)Yes you are correct the issue is HTTP_RAW_POST_DATA
was not allowed on my PHP.ini settings.
And hence was not getting posted.
Thanks for the great analysis , that too in the train:)
Thanks,
Astha
On Fri, Sep 19, 2008 at 6:12 PM, Chris Chabot <ch...@google.com> wrote:
> Looking at the rpc servlet:
>
> if (isset($GLOBALS['HTTP_RAW_POST_DATA']) || isset($_POST['request'])) {
> ...stuff ....
> } else {
> throw new Exception("No post data set");
> }
>
> So it looks both at the raw post, and a request=<foo> (hack for php, php
> client side doesnt really do raw posts so easily) and if neither are
> present
> it throws that error.
>
> In what way does the sample gadget now parse the info to the rpc service?
> get param or something?
>
> Should be easy & quick enough to fix in any case. I'm stuck in a train
> right
> now (thalys, rocks that they have wifi) but i'll take a look once im near a
> desk again :)
>
> 2008/9/19 Astha Bhatnagar <as...@gmail.com>
>
> > Hi Chris,
> > I actually tried latest shindig code and sample container. It is throwing
> > error
> >
> > <html><body><h1>Internal Server Error</h1><br />No post data set<br
> > /><pre>Array
> >
> > (
> >
> > [0] => Array
> >
> > (
> >
> > [file] => C:\wamp\www\shindig\php\index.php
> >
> > [line] => 109
> >
> > [function] => doPost
> >
> > [class] => JsonRpcServlet
> >
> > [object] => JsonRpcServlet Object
> >
> > (
> >
> > [lastModified:private] =>
> >
> > [contentType:private] => text/html
> >
> > [charset:private] => UTF-8
> >
> > [noCache:private] =>
> >
> > [cacheTime:private] => 86400
> >
> > [noHeaders] =>
> >
> > )
> >
> > [type] => ->
> >
> > [args] => Array
> >
> > (
> >
> > )
> >
> > )
> >
> > )
> >
> > </pre></body></html>
> >
> > but same samplecontainer is working fine with Java Shindig.
> >
> > That's why this issue came up.
> >
> > Regards,
> >
> > Astha
> >
> >
> > On Fri, Sep 19, 2008 at 5:03 PM, Chris Chabot <ch...@google.com>
> wrote:
> >
> > > PHP Shindig def does support the metadata call, see
> > >
> http://modules.partuza.nl/gadgets/files/container/sample-metadata.htmlas
> > > example. If there's something missing in the response structure, please
> > > file
> > > a JIRA issue for that.
> > >
> > > Json-RPC is being worked on, and hope to have that in somewhere next
> > week.
> > >
> > > 2008/9/18 Astha Bhatnagar <as...@gmail.com>
> > >
> > > > 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 <bo...@gmail.com>
> > > >
> > > > > 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 <bo...@gmail.com>
> > > > >
> > > > > > Hi,
> > > > > > I've attached the patch for the method that I use.
> > > > > >
> > > > > > Ben
> > > > > >
> > > > > >
> > > > > > 2008/9/12 John Hjelmstad <fa...@google.com>
> > > > > >
> > > > > >> 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 <et...@google.com>
> > > > > >>
> > > > > >> > 2008/9/12 John Hjelmstad <fa...@google.com>
> > > > > >> >
> > > > > >> > > 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 <et...@google.com>
> > > > > >> > >
> > > > > >> > > > 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 <bo...@gmail.com>
> > > > > >> > > >
> > > > > >> > > > > 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 <fa...@google.com> 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 <et...@google.com> 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 <
> > > > > >> fargo@google.com
> > > > > >> > >
> > > > > >> > > > > 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 <do...@apache.org> 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 <
> > > > > >> > > tamlyn@tamlyn.org
> > > > > >> > > > >
> > > > > >> > > > > >> > wrote:
> > > > > >> > > > > >> > >
> > > > > >> > > > > >> > > > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <
> > > > > doll@apache.org>
> > > > > >> > > 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.
> > > > > >> > > > > >> > > >
> > > > > >> > > > > >> > >
> > > > > >> > > > > >> >
> > > > > >> > > > > >>
> > > > > >> > > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: default_value not working
Posted by Chris Chabot <ch...@google.com>.
Looking at the rpc servlet:
if (isset($GLOBALS['HTTP_RAW_POST_DATA']) || isset($_POST['request'])) {
...stuff ....
} else {
throw new Exception("No post data set");
}
So it looks both at the raw post, and a request=<foo> (hack for php, php
client side doesnt really do raw posts so easily) and if neither are present
it throws that error.
In what way does the sample gadget now parse the info to the rpc service?
get param or something?
Should be easy & quick enough to fix in any case. I'm stuck in a train right
now (thalys, rocks that they have wifi) but i'll take a look once im near a
desk again :)
2008/9/19 Astha Bhatnagar <as...@gmail.com>
> Hi Chris,
> I actually tried latest shindig code and sample container. It is throwing
> error
>
> <html><body><h1>Internal Server Error</h1><br />No post data set<br
> /><pre>Array
>
> (
>
> [0] => Array
>
> (
>
> [file] => C:\wamp\www\shindig\php\index.php
>
> [line] => 109
>
> [function] => doPost
>
> [class] => JsonRpcServlet
>
> [object] => JsonRpcServlet Object
>
> (
>
> [lastModified:private] =>
>
> [contentType:private] => text/html
>
> [charset:private] => UTF-8
>
> [noCache:private] =>
>
> [cacheTime:private] => 86400
>
> [noHeaders] =>
>
> )
>
> [type] => ->
>
> [args] => Array
>
> (
>
> )
>
> )
>
> )
>
> </pre></body></html>
>
> but same samplecontainer is working fine with Java Shindig.
>
> That's why this issue came up.
>
> Regards,
>
> Astha
>
>
> On Fri, Sep 19, 2008 at 5:03 PM, Chris Chabot <ch...@google.com> wrote:
>
> > PHP Shindig def does support the metadata call, see
> > http://modules.partuza.nl/gadgets/files/container/sample-metadata.htmlas
> > example. If there's something missing in the response structure, please
> > file
> > a JIRA issue for that.
> >
> > Json-RPC is being worked on, and hope to have that in somewhere next
> week.
> >
> > 2008/9/18 Astha Bhatnagar <as...@gmail.com>
> >
> > > 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 <bo...@gmail.com>
> > >
> > > > 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 <bo...@gmail.com>
> > > >
> > > > > Hi,
> > > > > I've attached the patch for the method that I use.
> > > > >
> > > > > Ben
> > > > >
> > > > >
> > > > > 2008/9/12 John Hjelmstad <fa...@google.com>
> > > > >
> > > > >> 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 <et...@google.com>
> > > > >>
> > > > >> > 2008/9/12 John Hjelmstad <fa...@google.com>
> > > > >> >
> > > > >> > > 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 <et...@google.com>
> > > > >> > >
> > > > >> > > > 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 <bo...@gmail.com>
> > > > >> > > >
> > > > >> > > > > 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 <fa...@google.com> 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 <et...@google.com> 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 <
> > > > >> fargo@google.com
> > > > >> > >
> > > > >> > > > > 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 <do...@apache.org> 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 <
> > > > >> > > tamlyn@tamlyn.org
> > > > >> > > > >
> > > > >> > > > > >> > wrote:
> > > > >> > > > > >> > >
> > > > >> > > > > >> > > > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <
> > > > doll@apache.org>
> > > > >> > > 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.
> > > > >> > > > > >> > > >
> > > > >> > > > > >> > >
> > > > >> > > > > >> >
> > > > >> > > > > >>
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: default_value not working
Posted by Astha Bhatnagar <as...@gmail.com>.
Hi Chris,
I actually tried latest shindig code and sample container. It is throwing
error
<html><body><h1>Internal Server Error</h1><br />No post data set<br /><pre>Array
(
[0] => Array
(
[file] => C:\wamp\www\shindig\php\index.php
[line] => 109
[function] => doPost
[class] => JsonRpcServlet
[object] => JsonRpcServlet Object
(
[lastModified:private] =>
[contentType:private] => text/html
[charset:private] => UTF-8
[noCache:private] =>
[cacheTime:private] => 86400
[noHeaders] =>
)
[type] => ->
[args] => Array
(
)
)
)
</pre></body></html>
but same samplecontainer is working fine with Java Shindig.
That's why this issue came up.
Regards,
Astha
On Fri, Sep 19, 2008 at 5:03 PM, Chris Chabot <ch...@google.com> wrote:
> PHP Shindig def does support the metadata call, see
> http://modules.partuza.nl/gadgets/files/container/sample-metadata.html as
> example. If there's something missing in the response structure, please
> file
> a JIRA issue for that.
>
> Json-RPC is being worked on, and hope to have that in somewhere next week.
>
> 2008/9/18 Astha Bhatnagar <as...@gmail.com>
>
> > 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 <bo...@gmail.com>
> >
> > > 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 <bo...@gmail.com>
> > >
> > > > Hi,
> > > > I've attached the patch for the method that I use.
> > > >
> > > > Ben
> > > >
> > > >
> > > > 2008/9/12 John Hjelmstad <fa...@google.com>
> > > >
> > > >> 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 <et...@google.com>
> > > >>
> > > >> > 2008/9/12 John Hjelmstad <fa...@google.com>
> > > >> >
> > > >> > > 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 <et...@google.com>
> > > >> > >
> > > >> > > > 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 <bo...@gmail.com>
> > > >> > > >
> > > >> > > > > 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 <fa...@google.com> 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 <et...@google.com> 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 <
> > > >> fargo@google.com
> > > >> > >
> > > >> > > > > 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 <do...@apache.org> 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 <
> > > >> > > tamlyn@tamlyn.org
> > > >> > > > >
> > > >> > > > > >> > wrote:
> > > >> > > > > >> > >
> > > >> > > > > >> > > > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <
> > > doll@apache.org>
> > > >> > > 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.
> > > >> > > > > >> > > >
> > > >> > > > > >> > >
> > > >> > > > > >> >
> > > >> > > > > >>
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
Re: default_value not working
Posted by Chris Chabot <ch...@google.com>.
PHP Shindig def does support the metadata call, see
http://modules.partuza.nl/gadgets/files/container/sample-metadata.html as
example. If there's something missing in the response structure, please file
a JIRA issue for that.
Json-RPC is being worked on, and hope to have that in somewhere next week.
2008/9/18 Astha Bhatnagar <as...@gmail.com>
> 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 <bo...@gmail.com>
>
> > 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 <bo...@gmail.com>
> >
> > > Hi,
> > > I've attached the patch for the method that I use.
> > >
> > > Ben
> > >
> > >
> > > 2008/9/12 John Hjelmstad <fa...@google.com>
> > >
> > >> 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 <et...@google.com>
> > >>
> > >> > 2008/9/12 John Hjelmstad <fa...@google.com>
> > >> >
> > >> > > 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 <et...@google.com>
> > >> > >
> > >> > > > 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 <bo...@gmail.com>
> > >> > > >
> > >> > > > > 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 <fa...@google.com> 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 <et...@google.com> 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 <
> > >> fargo@google.com
> > >> > >
> > >> > > > > 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 <do...@apache.org> 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 <
> > >> > > tamlyn@tamlyn.org
> > >> > > > >
> > >> > > > > >> > wrote:
> > >> > > > > >> > >
> > >> > > > > >> > > > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <
> > doll@apache.org>
> > >> > > 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.
> > >> > > > > >> > > >
> > >> > > > > >> > >
> > >> > > > > >> >
> > >> > > > > >>
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: default_value not working
Posted by Astha Bhatnagar <as...@gmail.com>.
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 <bo...@gmail.com>
> 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 <bo...@gmail.com>
>
> > Hi,
> > I've attached the patch for the method that I use.
> >
> > Ben
> >
> >
> > 2008/9/12 John Hjelmstad <fa...@google.com>
> >
> >> 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 <et...@google.com>
> >>
> >> > 2008/9/12 John Hjelmstad <fa...@google.com>
> >> >
> >> > > 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 <et...@google.com>
> >> > >
> >> > > > 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 <bo...@gmail.com>
> >> > > >
> >> > > > > 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 <fa...@google.com> 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 <et...@google.com> 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 <
> >> fargo@google.com
> >> > >
> >> > > > > 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 <do...@apache.org> 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 <
> >> > > tamlyn@tamlyn.org
> >> > > > >
> >> > > > > >> > wrote:
> >> > > > > >> > >
> >> > > > > >> > > > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <
> doll@apache.org>
> >> > > 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.
> >> > > > > >> > > >
> >> > > > > >> > >
> >> > > > > >> >
> >> > > > > >>
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: default_value not working
Posted by ben bonfil <bo...@gmail.com>.
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 <bo...@gmail.com>
> Hi,
> I've attached the patch for the method that I use.
>
> Ben
>
>
> 2008/9/12 John Hjelmstad <fa...@google.com>
>
>> 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 <et...@google.com>
>>
>> > 2008/9/12 John Hjelmstad <fa...@google.com>
>> >
>> > > 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 <et...@google.com>
>> > >
>> > > > 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 <bo...@gmail.com>
>> > > >
>> > > > > 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 <fa...@google.com> 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 <et...@google.com> 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 <
>> fargo@google.com
>> > >
>> > > > > 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 <do...@apache.org> 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 <
>> > > tamlyn@tamlyn.org
>> > > > >
>> > > > > >> > wrote:
>> > > > > >> > >
>> > > > > >> > > > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <do...@apache.org>
>> > > 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.
>> > > > > >> > > >
>> > > > > >> > >
>> > > > > >> >
>> > > > > >>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: How can I use Basic Auth in my gadgets ?
Posted by Brian Eaton <be...@google.com>.
On Mon, Sep 15, 2008 at 11:55 AM, <al...@indt.org.br> wrote:
> I'm developing a Twitter gadget and I can't do the authentication with
> basic auth.
>
> Is there any way to do it ?
Once upon a time Twitter was working to support OAuth, but I'm not
sure how much progress they've made. You could try the twitter OAuth
development group:
http://groups.google.com/group/twitter-development-talk
How can I use Basic Auth in my gadgets ?
Posted by al...@indt.org.br.
Hi,
I'm developing a Twitter gadget and I can't do the authentication with
basic auth.
Is there any way to do it ?
Thanks!
Re: default_value not working
Posted by ben bonfil <bo...@gmail.com>.
Hi,
I've attached the patch for the method that I use.
Ben
2008/9/12 John Hjelmstad <fa...@google.com>
> 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 <et...@google.com>
>
> > 2008/9/12 John Hjelmstad <fa...@google.com>
> >
> > > 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 <et...@google.com>
> > >
> > > > 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 <bo...@gmail.com>
> > > >
> > > > > 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 <fa...@google.com> 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 <et...@google.com> 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 <
> fargo@google.com
> > >
> > > > > 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 <do...@apache.org> 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 <
> > > tamlyn@tamlyn.org
> > > > >
> > > > > >> > wrote:
> > > > > >> > >
> > > > > >> > > > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <do...@apache.org>
> > > 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.
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: default_value not working
Posted by John Hjelmstad <fa...@google.com>.
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 <et...@google.com>
> 2008/9/12 John Hjelmstad <fa...@google.com>
>
> > 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 <et...@google.com>
> >
> > > 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 <bo...@gmail.com>
> > >
> > > > 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 <fa...@google.com> 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 <et...@google.com> 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 <fargo@google.com
> >
> > > > 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 <do...@apache.org> 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 <
> > tamlyn@tamlyn.org
> > > >
> > > > >> > wrote:
> > > > >> > >
> > > > >> > > > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <do...@apache.org>
> > 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.
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: default_value not working
Posted by Kevin Brown <et...@google.com>.
2008/9/12 John Hjelmstad <fa...@google.com>
> 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 <et...@google.com>
>
> > 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 <bo...@gmail.com>
> >
> > > 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 <fa...@google.com> 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 <et...@google.com> 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 <fa...@google.com>
> > > 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 <do...@apache.org> 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 <
> tamlyn@tamlyn.org
> > >
> > > >> > wrote:
> > > >> > >
> > > >> > > > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <do...@apache.org>
> 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.
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>
Re: default_value not working
Posted by John Hjelmstad <fa...@google.com>.
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.
-John
2008/9/12 Kevin Brown <et...@google.com>
> 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 <bo...@gmail.com>
>
> > 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 <fa...@google.com> 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 <et...@google.com> 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 <fa...@google.com>
> > 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 <do...@apache.org> 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 <tamlyn@tamlyn.org
> >
> > >> > wrote:
> > >> > >
> > >> > > > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <do...@apache.org> 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.
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: default_value not working
Posted by Kevin Brown <et...@google.com>.
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 <bo...@gmail.com>
> 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 <fa...@google.com> 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 <et...@google.com> 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 <fa...@google.com>
> 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 <do...@apache.org> 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 <ta...@tamlyn.org>
> >> > wrote:
> >> > >
> >> > > > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <do...@apache.org> 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.
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: default_value not working
Posted by ben bonfil <bo...@gmail.com>.
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 <fa...@google.com> 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 <et...@google.com> 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 <fa...@google.com> 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 <do...@apache.org> 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 <ta...@tamlyn.org>
>> > wrote:
>> > >
>> > > > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <do...@apache.org> 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.
>> > > >
>> > >
>> >
>>
>
Re: default_value not working
Posted by John Hjelmstad <fa...@google.com>.
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 <et...@google.com> 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 <fa...@google.com> 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 <do...@apache.org> 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 <ta...@tamlyn.org>
> > wrote:
> > >
> > > > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <do...@apache.org> 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.
> > > >
> > >
> >
>
Re: default_value not working
Posted by Kevin Brown <et...@google.com>.
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 <fa...@google.com> 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 <do...@apache.org> 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 <ta...@tamlyn.org>
> wrote:
> >
> > > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <do...@apache.org> 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.
> > >
> >
>
Re: default_value not working
Posted by John Hjelmstad <fa...@google.com>.
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 <do...@apache.org> 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 <ta...@tamlyn.org> wrote:
>
> > On Tue, Sep 9, 2008 at 6:55 PM, Cassie <do...@apache.org> 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.
> >
>
Re: default_value not working
Posted by Cassie <do...@apache.org>.
(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 <ta...@tamlyn.org> wrote:
> On Tue, Sep 9, 2008 at 6:55 PM, Cassie <do...@apache.org> 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.
>
Re: default_value not working
Posted by Tamlyn Rhodes <ta...@tamlyn.org>.
On Tue, Sep 9, 2008 at 6:55 PM, Cassie <do...@apache.org> 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.
Re: default_value not working
Posted by Cassie <do...@apache.org>.
Hey Tamlyn - do you think you could make this into a patch and attach it to
a jira issue for Shindig?
See our website for more info about how to do this:
http://incubator.apache.org/shindig/#tab-contribute
Thanks!
- Cassie
On Tue, Sep 9, 2008 at 8:57 AM, Tamlyn Rhodes <ta...@tamlyn.org> wrote:
> For anyone else having this problem here is how I solved it. If
> there's a better way please let me know.
>
> When adding a new gadget I do a call to /gadgets/metadata which
> fetches the default values for each userPref. Then I do:
>
>
>
> 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();
>
>
>
> Cheers,
>
> Tamlyn.
>
Re: default_value not working
Posted by Tamlyn Rhodes <ta...@tamlyn.org>.
For anyone else having this problem here is how I solved it. If
there's a better way please let me know.
When adding a new gadget I do a call to /gadgets/metadata which
fetches the default values for each userPref. Then I do:
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();
Cheers,
Tamlyn.