W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: [A&E] Last Call comments (2): discovery & localization

From: Marcos Caceres <marcosc@opera.com>
Date: Mon, 21 Sep 2009 20:08:43 +0200
Message-ID: <b21a10670909211108i7993197bp12cac9e7348473db@mail.gmail.com>
To: Marcin Hanclik <Marcin.Hanclik@access-company.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>
2009/9/15 Marcin Hanclik <Marcin.Hanclik@access-company.com>:
> The below comments refer to:
>
> Widgets 1.0: The widget Interface
>
> Editor's Draft 14 September 2009
>
>
>
> 5.1
>
> Configuration Attributes Table does not contain features/params.
>
> We may assume that when the widget gets installed and loaded, the mandatory (@required=true) features were present/accessible.

right.

> However, the widget does not know whether the optional features (@required=false)  are present/accessible.

It is out of scope to define how bindings to features occur. The
specification of a feature must define it's own binding.

That is, imagine a world where:

<widget ...
 id="skynet:T-800"
>
  <feature uri="skynet:crushPunyHumans"/>
  <feature uri="skynet:heatSeek" required="false"/>
  <content src="T800.skynet" type="application/x-skynet-cyborg" />
</widget>

... in T800.skynet...
//check for optional heatSeek feature..
if(this.heatSeek){
  this.heatSeek.scanForPunyCrushableHumans();
}

Where Skynet's Infrared Sensor specification 1.0 contains WebIDL that
supplements the Terminator object.

[Supplemental, NoInterfaceObject]
interface HeatSeek {
  readonly attribute HeatSeek heatSeek;
};

Terminator implements HeatSeek;

> Therefore, I suggest adding the list of available features to the widget object. E.g. as an array of IRI or by means of a query API (or shall hasFeature() work? Not sure why it was removed from the previous WD) so that the widget could discover the available components/features.

What you are suggesting is redundant. If you want to discover if you
have a feature, try to run it. If you don't have it, and you needed
it, then the widget already failed. If you don't have it, and you
don't need it, then just check for its presence (ala,
if(this.whateverFeature)) .

> 5.1
>
> Localization
>
> Shall it be possible for the widget to programmatically discover the localization path it was loaded from (section 9 of P&C)?

Yes, you can check its URI. If the implementation supports the window
object, then it possible.

> [ I understand the folder-based and element-based localizations are specified in P&C and wonder why it is not possible to programmatically discover the localization that was applied (it could also help with testing IMHO). ]
>

Yes, the widget URI scheme will return you the full path though
conventional (DOM/Window Object) methods. Note that with the model we
use, content can come from multiple locales.

-- 
Marcos Caceres
http://datadriven.com.au
Received on Monday, 21 September 2009 18:09:24 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT