W3C home > Mailing lists > Public > public-appformats@w3.org > November 2006

Re: [Widgets] also a feedback

From: Marcos Caceres <m.caceres@qut.edu.au>
Date: Mon, 13 Nov 2006 13:09:25 +1000
Message-ID: <4557E1E5.5010707@qut.edu.au>
To: Michael Rupp <ruppml@googlemail.com>
CC: public-appformats@w3.org

Hi Michael,
Thanks for the feedback.

Michael Rupp wrote:
> Hello,
> i just read the Widgets-Working Draft and had some thoughts about that,
> so i write them:
> I agree with the idea of changing the name of the root node:
> <component> or <module> would be my favorites, i think Names like
> <configuration> or <about> are not useful in a file already called 
> config.xml.
Ok, so there is currently not much consensus on this;  I guess we need 
to consider whether the metadata is the widget (as it is currently 
proposed with <widget>) or if the metadata is making assertions about a 
resource (as would be the case with <configuration> or <manifest>)... 
think RDF without actually using it. I think most people would agree 
that metadata (config.xml) *is not* the widget, but describes particular 
things about it. 
> In either case the "widgetname"-Node has to be changed accordingly.
Agreed, what do you suggest as an alternative?
> I like the width and height-Nodes, for the reasons Marcos Caceres wrote,
> so you can create a layout of all widgets before actually loading them.
I'm still not 100% on the practical application of these elements; but 
like you said, there is possibly a valid reason for having them. Need to 
investigate this further.
> Instead of the <id>-Node I would suggest a more complex structure like:
> <version>
>     <id>10.1</id>
>     <timestamp>12345</timestamp>
>     <source>http://www.getmehere.com/widget1.zip</source>
> </version>
> Although some might say, that this is more information then needed.
Interesting. I am also looking at the Firefox Extensions manifest format 
and how they deal with similar kinds of stuff.

> On the Interfaces:
> I don't get the point on the openURL()-Method. Isn't that a feature 
> the Engine
> has to implement and the Widget has to call, when someone clicks on a 
> Link
> inside the Widget? I think a method like parseData() makes more sense, 
> with wich
> you can order a Widget to use specific data to manipulate.
I think OpenURL() should open a web page inside a new browser window. 
XHR is usually used for what you mention above. Regarding, parseData, 
there are lots of different types of data you could parse (xml, rss, 
json, csv, html, etc), which might make parseData kinda impractical 
because they all have their own unique parsing requirements.
> Reading about the Window-Interface i ask myself how to manage Z-Ordering,
> Minimizing, Maximizing, Hiding? perhaps some of this stuff could be 
> part of the
> widget, while some of it has to be handled by the Engine.
We are currently looking at the overlap between the Window and Widget 
objects. We know there is a lot overlap and we will work towards a 
common solution.

Received on Monday, 13 November 2006 03:10:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:05 UTC