You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@shindig.apache.org by Darren Bond <db...@globalcad.com> on 2013/11/12 19:50:09 UTC
Catch Request to Display UserPrefs Dialog
Dear All,
Our gadgets have an "Edit Settings" menu item, accessible via each gadget's
title bar, which displays the gadget's UserPrefs dialog (typical iGoogle
style behaviour). This functionality is working well.
Now we have developed a Weather gadget, who's initial state displays a "Set
Up" button within the gadget's window.
The question is how can we enable this button to display the gadget's
UserPrefs dialog when clicked? Does Shindig have a kind of event that could
be published outside so that a gadget's container (our website) can catch it
and handle it as required?
The required action is shown in this image -
http://download.globalcad.com/Weather_Gadget_Button_UserPrefs.png
The current logic we use to enable the gadget title bar's "Edit Settings"
menu item is via the Shindig 'set' and 'setArray' methods...
http://opensocial-resources.googlecode.com/svn/spec/trunk/Core-Gadget.xml#ga
dgets.Prefs.set
http://opensocial-resources.googlecode.com/svn/spec/trunk/Core-Gadget.xml#ga
dgets.Prefs.setArray
And a client side subscribes and catches them registering its own
function-handler by gadgets.rpc.register('set_pref', setPrefs).
Thanks.
Kind regards,
Darren
Re: Catch Request to Display UserPrefs Dialog
Posted by "Davies,Douglas" <da...@oclc.org>.
We do exactly that same approach and it works well.
On 11/18/13, 8:32 AM, "Stanton Sievers" <ss...@apache.org> wrote:
>Another approach I've seen, and one that Apache Rave uses, is to allow a
>gadget to define a "preferences" view that the container will render when
>the "Edit Settings" menu item is clicked. If the "preferences" view is
>not
>present in the gadget, the container will render its own preferences UI.
>
>This approach allows you to navigate the gadget to the "preferences" view
>or to open the gadget to the "preferences" view when the "Set up" button
>is
>clicked.
>
>
>On Tue, Nov 12, 2013 at 5:21 PM, Ryan Baxter <rb...@gmail.com> wrote:
>
>> The "typical" user experience would not involve opening the containers
>> preferences UI. The gadget would display its own UI allowing the user
>> to set the values and then call the set prefs APIs to tell the
>> container about the new preference values. If the user then went to
>> the container preferences UI the new values would be displayed there.
>> What you trying to accomplish is not wrong in any way but Shindig
>> doesn't have a default way to accomplish it. What you are doing with
>> the RPC handler seems like the best approach. Although I would
>> probably not hook into existing RPC APIs but instead create my own
>> that just opens the preferences UI in the container. You could then
>> take it one step further and wrap this in a feature for the gadgets of
>> your container to use. That way they can mark the feature optional
>> and fall back to the traditional way of setting preferences if they
>> are not rendered in your container.
>>
>> On Tue, Nov 12, 2013 at 1:50 PM, Darren Bond <db...@globalcad.com>
>>wrote:
>> > Dear All,
>> >
>> >
>> >
>> > Our gadgets have an "Edit Settings" menu item, accessible via each
>> gadget's
>> > title bar, which displays the gadget's UserPrefs dialog (typical
>>iGoogle
>> > style behaviour). This functionality is working well.
>> >
>> >
>> >
>> > Now we have developed a Weather gadget, who's initial state displays a
>> "Set
>> > Up" button within the gadget's window.
>> >
>> >
>> >
>> > The question is how can we enable this button to display the gadget's
>> > UserPrefs dialog when clicked? Does Shindig have a kind of event that
>> could
>> > be published outside so that a gadget's container (our website) can
>> catch it
>> > and handle it as required?
>> >
>> >
>> >
>> > The required action is shown in this image -
>> > http://download.globalcad.com/Weather_Gadget_Button_UserPrefs.png
>> >
>> >
>> >
>> > The current logic we use to enable the gadget title bar's "Edit
>>Settings"
>> > menu item is via the Shindig 'set' and 'setArray' methods...
>> >
>> >
>>
>>http://opensocial-resources.googlecode.com/svn/spec/trunk/Core-Gadget.xml
>>#ga
>> > dgets.Prefs.set
>> >
>> >
>>
>>http://opensocial-resources.googlecode.com/svn/spec/trunk/Core-Gadget.xml
>>#ga
>> > dgets.Prefs.setArray
>> >
>> > And a client side subscribes and catches them registering its own
>> > function-handler by gadgets.rpc.register('set_pref', setPrefs).
>> >
>> >
>> >
>> > Thanks.
>> >
>> >
>> >
>> > Kind regards,
>> >
>> >
>> >
>> > Darren
>> >
>>
Re: Catch Request to Display UserPrefs Dialog
Posted by Stanton Sievers <ss...@apache.org>.
Another approach I've seen, and one that Apache Rave uses, is to allow a
gadget to define a "preferences" view that the container will render when
the "Edit Settings" menu item is clicked. If the "preferences" view is not
present in the gadget, the container will render its own preferences UI.
This approach allows you to navigate the gadget to the "preferences" view
or to open the gadget to the "preferences" view when the "Set up" button is
clicked.
On Tue, Nov 12, 2013 at 5:21 PM, Ryan Baxter <rb...@gmail.com> wrote:
> The "typical" user experience would not involve opening the containers
> preferences UI. The gadget would display its own UI allowing the user
> to set the values and then call the set prefs APIs to tell the
> container about the new preference values. If the user then went to
> the container preferences UI the new values would be displayed there.
> What you trying to accomplish is not wrong in any way but Shindig
> doesn't have a default way to accomplish it. What you are doing with
> the RPC handler seems like the best approach. Although I would
> probably not hook into existing RPC APIs but instead create my own
> that just opens the preferences UI in the container. You could then
> take it one step further and wrap this in a feature for the gadgets of
> your container to use. That way they can mark the feature optional
> and fall back to the traditional way of setting preferences if they
> are not rendered in your container.
>
> On Tue, Nov 12, 2013 at 1:50 PM, Darren Bond <db...@globalcad.com> wrote:
> > Dear All,
> >
> >
> >
> > Our gadgets have an "Edit Settings" menu item, accessible via each
> gadget's
> > title bar, which displays the gadget's UserPrefs dialog (typical iGoogle
> > style behaviour). This functionality is working well.
> >
> >
> >
> > Now we have developed a Weather gadget, who's initial state displays a
> "Set
> > Up" button within the gadget's window.
> >
> >
> >
> > The question is how can we enable this button to display the gadget's
> > UserPrefs dialog when clicked? Does Shindig have a kind of event that
> could
> > be published outside so that a gadget's container (our website) can
> catch it
> > and handle it as required?
> >
> >
> >
> > The required action is shown in this image -
> > http://download.globalcad.com/Weather_Gadget_Button_UserPrefs.png
> >
> >
> >
> > The current logic we use to enable the gadget title bar's "Edit Settings"
> > menu item is via the Shindig 'set' and 'setArray' methods...
> >
> >
> http://opensocial-resources.googlecode.com/svn/spec/trunk/Core-Gadget.xml#ga
> > dgets.Prefs.set
> >
> >
> http://opensocial-resources.googlecode.com/svn/spec/trunk/Core-Gadget.xml#ga
> > dgets.Prefs.setArray
> >
> > And a client side subscribes and catches them registering its own
> > function-handler by gadgets.rpc.register('set_pref', setPrefs).
> >
> >
> >
> > Thanks.
> >
> >
> >
> > Kind regards,
> >
> >
> >
> > Darren
> >
>
Re: Catch Request to Display UserPrefs Dialog
Posted by Ryan Baxter <rb...@gmail.com>.
The "typical" user experience would not involve opening the containers
preferences UI. The gadget would display its own UI allowing the user
to set the values and then call the set prefs APIs to tell the
container about the new preference values. If the user then went to
the container preferences UI the new values would be displayed there.
What you trying to accomplish is not wrong in any way but Shindig
doesn't have a default way to accomplish it. What you are doing with
the RPC handler seems like the best approach. Although I would
probably not hook into existing RPC APIs but instead create my own
that just opens the preferences UI in the container. You could then
take it one step further and wrap this in a feature for the gadgets of
your container to use. That way they can mark the feature optional
and fall back to the traditional way of setting preferences if they
are not rendered in your container.
On Tue, Nov 12, 2013 at 1:50 PM, Darren Bond <db...@globalcad.com> wrote:
> Dear All,
>
>
>
> Our gadgets have an "Edit Settings" menu item, accessible via each gadget's
> title bar, which displays the gadget's UserPrefs dialog (typical iGoogle
> style behaviour). This functionality is working well.
>
>
>
> Now we have developed a Weather gadget, who's initial state displays a "Set
> Up" button within the gadget's window.
>
>
>
> The question is how can we enable this button to display the gadget's
> UserPrefs dialog when clicked? Does Shindig have a kind of event that could
> be published outside so that a gadget's container (our website) can catch it
> and handle it as required?
>
>
>
> The required action is shown in this image -
> http://download.globalcad.com/Weather_Gadget_Button_UserPrefs.png
>
>
>
> The current logic we use to enable the gadget title bar's "Edit Settings"
> menu item is via the Shindig 'set' and 'setArray' methods...
>
> http://opensocial-resources.googlecode.com/svn/spec/trunk/Core-Gadget.xml#ga
> dgets.Prefs.set
>
> http://opensocial-resources.googlecode.com/svn/spec/trunk/Core-Gadget.xml#ga
> dgets.Prefs.setArray
>
> And a client side subscribes and catches them registering its own
> function-handler by gadgets.rpc.register('set_pref', setPrefs).
>
>
>
> Thanks.
>
>
>
> Kind regards,
>
>
>
> Darren
>