- From: Marcos Caceres <marcosc@opera.com>
- Date: Mon, 21 Sep 2009 20:08:43 +0200
- 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 UTC