Re: [widgets] Declarative support for a widget's metadata

Hi Marcos,

PALETTE adopted this mechanism in their extension profile of the spec,  
and it seems like a very useful addition. Its also used in some web  
widget galleries to dynamically expose preferences to users as setup  
forms prior to installing a widget.

The only caveat would be if such a mechanism is optional, is its  
effect on interoperability - for example, we were unable to import and  
reuse widgets written by the Palette team, because the authors assumed  
that the widget engine had read the preferences and set the defaults;  
when this didn't occur (i.e. specified preferences were not  
initialised) the widgets broke.

So if a <preference> value is declared, there needs to be good  
guidance for widget developers on what to expect - e.g. if you specify  
<preference name="x" value="y"> in the manifest, don't always assume  
that this will be set by the engine, and have your JS able to handle  
getPreference("x") returning null and not "y".

S

On 19 Feb 2009, at 17:59, Marcos Caceres wrote:

> On Thu, Feb 19, 2009 at 6:47 PM, Arthur Barstow  
> <art.barstow@nokia.com> wrote:
>> Marcos,
>>
>> A few weeks ago we talked about how a widget author could add
>> widget-specific metadata (e.g. initial settings) to the config file  
>> [1].
>>
>> I think providing a declarative means to provide this metadata is  
>> consistent
>> with existing Req #14 - Widget Metadata [2]. Additionally, at least  
>> some of
>> the Widget User Agents in the Widgets Landscape document also  
>> support this
>> functionality [3].
>>
>> The type of syntax to support this would be something like:
>>
>> <preference name="..." value="..."/>
>>
>> And the A&E's getPreference method [4] would return the value  
>> attribute's
>> value.
>>
>> I realize an author can define all of its widget-specific metadata  
>> in script
>> but having the data defined in the config file is consistent with  
>> some
>> existing WUAs.
>>
>> WDYT?
>
> I think this is a good idea, though it does replicate some of the
> functionality provided by the setPreference API. However, if other
> people want this, I'm happy to specify it. It should not be very
> difficult to do. Things set by the <preference> element will
> automatically appear in the preferences object at runtime (or in
> session storage, if we go down that route). These values will only be
> set when the widget is first run. setPreference() can override the
> values once the widget is running.
>
> Kind regards,
> Marcos
>
> -- 
> Marcos Caceres
> http://datadriven.com.au
>