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

Mon, 23 Feb 2009 04:43:35 -0800 

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  
<[email protected]> 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






Attachment:
smime.p7s

Description: S/MIME cryptographic signature






















					Reply via email to