Re: Widgets 1.0 - widget settings: publishing / modifications

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
<marcosscaceres@gmail.com> wrote:
> Hi Sergey,
>
>
>  On Thu, Mar 13, 2008 at 1:07 AM, Sergey Ilinsky <castonet@yahoo.co.uk> 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

Received on Friday, 14 March 2008 05:30:13 UTC