Re: Widgets 1.0 - widget settings: publishing / modifications

Hi Marcos,

It's clear. As long as settings are not considered as part of a widget there is of course no need in <setting name="" default="" type=""/> element or event-based change notification mechanism (that makes sense only in case whose settings could be modified from the Widget runtime UI).

But then you would not need the already added to the specification "preferenceForKey / setPreferenceForKey" API. You could rather use storage object defined in HTML5.

However i still think there is a need for the mentioned additions. Whose would cover dashboard-like Widget runtime requirements (most of such runtimes make use of them), while leaving widget developer an opportunity to implement the settings management customly.

Sergey/



Marcos Caceres <marcosscaceres@gmail.com> wrote: 
Hi Sergey,

I've thought about it some more and I don't think we need a custom
event model for preferences. The preference UI is just going to be
created with HTML/Script anyway so the author has full explicit
control over all changes (unlike Yahoo! Widgets, which uses a custom
preferences UI so preference-change events make sense). Instead,
developers can build a simple wrapper around preference getting and
setting.. eg:

PrefManager = {
  hasPref: function(key){.... true or false...},
  setPref: function(key, value){ ... setPreferenceForKey(), broadcast
event to listeners... },
  getPref: function(key){ ... get key.....},
  deletePref: function(key){... broadcast custom change event....},
  subscribe: function(callback) { ... ... },
  unsubscribe: function(someFunction){  ... like using addEventListener... },
  //you can get fancy too
  watchKey: function(someKey, callback){ ... ...},
  ..and so on....
}

I think this is simpler, more flexible, and meets the use case. What
do you think?

Kind regards,
Marcos

On Thu, Mar 13, 2008 at 7:24 PM, Marcos Caceres
 wrote:
> Hi Sergey,
>
>
>  On Thu, Mar 13, 2008 at 1:07 AM, Sergey Ilinsky  wrote:
>  > Not sure if the issue was previously discussed -
>  > I could not find its trails anyway..
>  >
>  > If I understand correctly, the purpose of the following API
>  > functions preferenceForKey / setPreferenceForKey
>  > available on Widget interface is to query widget runtime for
>  > "widget instance" - specific settings.
>  >
>  > Then several questions/issues come:
>  >
>  > 1) will there be a "setting" element available
>  >  in the configuration file for the purpose of publishing
>  >  widget settings? (Widget runtime could then, for example,
>  >  provide a consistent UI for editing settings)
>
>  Probably not (though the Open Ajax Alliance (OAA) is working on this
>  in their metadata format). I strongly believe that the preferences
>  should be set "onload" using script. Personally, and in the case of
>  the kind widgets we are defining, I think it would be messy to have
>  preferences being set in the config file. For one, it would mean
>  having to define a bunch of types that ECMAScript already gives us.
>  Also, I think the preference UI is better custom built using HTML.
>
>
>  > 2) how a widget will then be notified on settings changes
>  >  made from the widget runtime UI?
>
>  Good point. We will probably add an event for that...  or something like:
>
>  widget.addEventListener("preferenceChange", listener, true|false);
>
>  Or
>
>  widget.onPreferencesChanged = function(event){ ...do something with event... }
>
>  and the event object might contain the key, the new value, and the old value:
>
>  interface PreferenceChagedEvent : Event {
>   readonly attribute DOMString        prevValue;
>   readonly attribute DOMString        newValue;
>   readonly attribute DOMString        preferenceKey;
>  };
>
>
>  Kind regards,
>  Marcos
>  --
>  Marcos Caceres
>  http://datadriven.com.au
>



-- 
Marcos Caceres
http://datadriven.com.au



       
---------------------------------
 Rise to the challenge for Sport Relief with Yahoo! for Good