Re: [widgets-twi] window object

2010-02-11 Thread Marcos Caceres
On Tue, Feb 9, 2010 at 4:05 PM, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
 In Wookie we just create the widget object in the global scope, and then add
 it as an attribute to the window object. Author scripts can access it either
 by window.widget or just plain widget.
 I wonder though - for authors what should we recommend if they want their
 widget to run unmodified in the most UAs?

I think window.widget would be best.



-- 
Marcos Caceres
http://datadriven.com.au



Re: [widgets-twi] window object

2010-02-09 Thread Cyril Concolato

Le 08/02/2010 13:29, Robin Berjon a écrit :

On Feb 5, 2010, at 16:18 , Marcos Caceres wrote:

On Thu, Feb 4, 2010 at 6:41 PM, Cyril Concolatocyril.concol...@enst.fr  wrote:

So I'm wondering how should the widget object be implemented in a UA
that does not support the window object ?


Yeah, that's a tough one... the spec says:

For a widget instance, a user agent MUST expose a unique object that
implements the widget interface to author scripts.

It does not give any guidance as to how the interface must be exposed.


But then again, SVG supports the Window object (minimally defined in 
http://www.w3.org/TR/SVGMobile12/svgudom.html#dom__Window). So just adding a 
widget field there ought to be straightforward.

My mistake. I had not realized that. But again, the question is why put the 
widget object on the window object, apart from it being a black hole. Why not 
put it in the global object. What's wrong with that? It would easier to 
specify. What's the benefit of using the window object?

Cyril
--
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Mutimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France
http://concolato.blog.telecom-paristech.fr/



Re: [widgets-twi] window object

2010-02-09 Thread Marcos Caceres
On Tue, Feb 9, 2010 at 9:54 AM, Cyril Concolato cyril.concol...@enst.fr wrote:
 Le 08/02/2010 13:29, Robin Berjon a écrit :

 On Feb 5, 2010, at 16:18 , Marcos Caceres wrote:

 On Thu, Feb 4, 2010 at 6:41 PM, Cyril Concolatocyril.concol...@enst.fr
  wrote:

 So I'm wondering how should the widget object be implemented in a UA
 that does not support the window object ?

 Yeah, that's a tough one... the spec says:

 For a widget instance, a user agent MUST expose a unique object that
 implements the widget interface to author scripts.

 It does not give any guidance as to how the interface must be exposed.

 But then again, SVG supports the Window object (minimally defined in
 http://www.w3.org/TR/SVGMobile12/svgudom.html#dom__Window). So just adding a
 widget field there ought to be straightforward.

 My mistake. I had not realized that. But again, the question is why put the
 widget object on the window object, apart from it being a black hole. Why
 not put it in the global object. What's wrong with that? It would easier to
 specify. What's the benefit of using the window object?

I don't think there is a way around this. Everything lives in the
window: it is the top level scope. This is evident by running
scriptalert(this)/script, which returns [object Window] or
[object DOMWindow]. Changing this to have Widget as the top or as a
shared top level scope would break code expecting to window object to
be there. Also, it might not even be possible to have two objects be
at the level scope at the same time.


-- 
Marcos Caceres
http://datadriven.com.au



Re: [widgets-twi] window object

2010-02-09 Thread Robin Berjon
On Feb 9, 2010, at 09:54 , Cyril Concolato wrote:
 My mistake. I had not realized that. But again, the question is why put the 
 widget object on the window object, apart from it being a black hole. Why not 
 put it in the global object. What's wrong with that? It would easier to 
 specify. What's the benefit of using the window object?

The Window object is the global object. Except it gets a little bit more 
complicated around WindowProxy.

-- 
Robin Berjon - http://berjon.com/






Re: [widgets-twi] window object

2010-02-09 Thread Scott Wilson


On 9 Feb 2010, at 09:22, Marcos Caceres wrote:

On Tue, Feb 9, 2010 at 9:54 AM, Cyril Concolato cyril.concol...@enst.fr 
 wrote:

Le 08/02/2010 13:29, Robin Berjon a écrit :


On Feb 5, 2010, at 16:18 , Marcos Caceres wrote:


On Thu, Feb 4, 2010 at 6:41 PM, Cyril Concolatocyril.concol...@enst.fr 


 wrote:


So I'm wondering how should the widget object be implemented in  
a UA

that does not support the window object ?


Yeah, that's a tough one... the spec says:

For a widget instance, a user agent MUST expose a unique object  
that

implements the widget interface to author scripts.

It does not give any guidance as to how the interface must be  
exposed.


But then again, SVG supports the Window object (minimally defined in
http://www.w3.org/TR/SVGMobile12/svgudom.html#dom__Window). So  
just adding a

widget field there ought to be straightforward.


My mistake. I had not realized that. But again, the question is why  
put the
widget object on the window object, apart from it being a black  
hole. Why
not put it in the global object. What's wrong with that? It would  
easier to

specify. What's the benefit of using the window object?


I don't think there is a way around this. Everything lives in the
window: it is the top level scope. This is evident by running
scriptalert(this)/script, which returns [object Window] or
[object DOMWindow]. Changing this to have Widget as the top or as a
shared top level scope would break code expecting to window object to
be there. Also, it might not even be possible to have two objects be
at the level scope at the same time.


In Wookie we just create the widget object in the global scope, and  
then add it as an attribute to the window object. Author scripts can  
access it either by window.widget or just plain widget.


I wonder though - for authors what should we recommend if they want  
their widget to run unmodified in the most UAs?


S

smime.p7s
Description: S/MIME cryptographic signature


Re: [widgets-twi] window object

2010-02-08 Thread Robin Berjon
On Feb 5, 2010, at 16:18 , Marcos Caceres wrote:
 On Thu, Feb 4, 2010 at 6:41 PM, Cyril Concolato cyril.concol...@enst.fr 
 wrote:
 So I'm wondering how should the widget object be implemented in a UA
 that does not support the window object ?
 
 Yeah, that's a tough one... the spec says:
 
 For a widget instance, a user agent MUST expose a unique object that
 implements the widget interface to author scripts.
 
 It does not give any guidance as to how the interface must be exposed.

But then again, SVG supports the Window object (minimally defined in 
http://www.w3.org/TR/SVGMobile12/svgudom.html#dom__Window). So just adding a 
widget field there ought to be straightforward.

-- 
Robin Berjon - http://berjon.com/






Re: [widgets-twi] window object

2010-02-08 Thread Marcos Caceres



Robin Berjon wrote:

On Feb 5, 2010, at 16:18 , Marcos Caceres wrote:

On Thu, Feb 4, 2010 at 6:41 PM, Cyril Concolatocyril.concol...@enst.fr  wrote:

So I'm wondering how should the widget object be implemented in a UA
that does not support the window object ?

Yeah, that's a tough one... the spec says:

For a widget instance, a user agent MUST expose a unique object that
implements the widget interface to author scripts.

It does not give any guidance as to how the interface must be exposed.


But then again, SVG supports the Window object (minimally defined in 
http://www.w3.org/TR/SVGMobile12/svgudom.html#dom__Window). So just adding a 
widget field there ought to be straightforward.


As much as I dislike it, I'm also not that inclined to define what to do 
for non-Window-based implementations (beyond what we currently have in 
the spec; which, I admit, is not much). It is, non-the-less, kinda bad 
that we don't have a spec that defines Window independently of HTML but 
I understand why that is: because Window is a foul intertwined 
incestuous mess... However, as Window is an integral part of the Web 
platform, we might just have to live with that :(


Also, the main use cases we are dealing with all rely on Window being 
there (HTML and, as Robin points out, SVG). If UAs start to emerge that 
are windowless (e.g., daemon or headless widgets), then we should 
formally define how this binds to some top-level context. WDYT?


Kind regards,
Marcos



Re: [widgets-twi] window object

2010-02-08 Thread Robin Berjon
On Feb 8, 2010, at 13:51 , Marcos Caceres wrote:
 As much as I dislike it, I'm also not that inclined to define what to do for 
 non-Window-based implementations (beyond what we currently have in the 
 spec; which, I admit, is not much).

I don't think that we could even if we wanted to. Presumably, any technology 
that embeds Javascript will have to have defined a global object of some form 
or other (I don't see how it works otherwise) but the exact details will either 
1) be copied from HTML or 2) be something different that we can't predict. So 
for (1) it'll be obvious what to do, for (2) it's obvious that we can't do 
anything to help.

 It is, non-the-less, kinda bad that we don't have a spec that defines Window 
 independently of HTML but I understand why that is: because Window is a foul 
 intertwined incestuous mess...

Actually, the reason is because we don't have an editor for it. If we did, 
Window could get split out of HTML (as it used to be).

 Also, the main use cases we are dealing with all rely on Window being there 
 (HTML and, as Robin points out, SVG). If UAs start to emerge that are 
 windowless (e.g., daemon or headless widgets), then we should formally 
 define how this binds to some top-level context. WDYT?

Yeah, but we can cross that bridge if and when we get there.

-- 
Robin Berjon - http://berjon.com/






Re: [widgets-twi] window object

2010-02-08 Thread Marcos Caceres



Robin Berjon wrote:

On Feb 8, 2010, at 13:51 , Marcos Caceres wrote:

As much as I dislike it, I'm also not that inclined to define what to do for 
non-Window-based implementations (beyond what we currently have in the spec; 
which, I admit, is not much).


I don't think that we could even if we wanted to. Presumably, any technology 
that embeds Javascript will have to have defined a global object of some form 
or other (I don't see how it works otherwise) but the exact details will either 
1) be copied from HTML or 2) be something different that we can't predict. So 
for (1) it'll be obvious what to do, for (2) it's obvious that we can't do 
anything to help.


Agreed.


It is, non-the-less, kinda bad that we don't have a spec that defines Window 
independently of HTML but I understand why that is: because Window is a foul 
intertwined incestuous mess...


Actually, the reason is because we don't have an editor for it. If we did, 
Window could get split out of HTML (as it used to be).


No, I don't mean split in editorial terms. I mean in the way it 
interweaves its slimy windowy tentacles into everything else and how 
everything relies on it being there. Like Storage firing events on it, 
etc. They should have called it the BlackHole interface, as there is no 
escape:)



Also, the main use cases we are dealing with all rely on Window being there (HTML and, as Robin 
points out, SVG). If UAs start to emerge that are windowless (e.g., daemon or 
headless widgets), then we should formally define how this binds to some top-level 
context. WDYT?


Yeah, but we can cross that bridge if and when we get there.


Agreed.




Re: [widgets-twi] window object

2010-02-05 Thread Marcos Caceres
On Thu, Feb 4, 2010 at 6:41 PM, Cyril Concolato cyril.concol...@enst.fr wrote:
 Hi all,

 After PC, I'm looking now at the Widget Interface spec, in particular to
 check the test suite and produce the implementation report. I have a problem
 with the spec. In GPAC, we implement only SVG not HTML5, with the Window
 object.

Hmm... to support SVG, what we should do is externalize the javascript
of each test. Then just use a script element to include the same code
into both files. Do you think you could help me do this?

Basically, what we would need to do is:

1. check if the current scripts work in an SVG context - and fix if they don't.
2. make the SVG templates (index.svg).
3. externalize all the JS (call them all test.js).
4. Replace all the HTML files.

I'm not sure what we will do with all the automatically generated
tests. We will need some guidance there from Dom, as I don't know how
that generator works.

So I'm wondering how should the widget object be implemented in a UA
 that does not support the window object ?

Yeah, that's a tough one... the spec says:

For a widget instance, a user agent MUST expose a unique object that
implements the widget interface to author scripts.

It does not give any guidance as to how the interface must be exposed.


-- 
Marcos Caceres
http://datadriven.com.au



Re: [widgets-twi] window object

2010-02-05 Thread Cyril Concolato

Le 05/02/2010 16:18, Marcos Caceres a écrit :

On Thu, Feb 4, 2010 at 6:41 PM, Cyril Concolatocyril.concol...@enst.fr  wrote:

Hi all,

After PC, I'm looking now at the Widget Interface spec, in particular to
check the test suite and produce the implementation report. I have a problem
with the spec. In GPAC, we implement only SVG not HTML5, with the Window
object.


Hmm... to support SVG, what we should do is externalize the javascript
of each test. Then just use a script element to include the same code
into both files. Do you think you could help me do this?

Basically, what we would need to do is:

1. check if the current scripts work in an SVG context - and fix if they don't.
2. make the SVG templates (index.svg).
3. externalize all the JS (call them all test.js).
4. Replace all the HTML files.

Here is a first try. I've made the test.js with the widget related code and the 
SVG/HTML related code is in the SVG/HTML file. However, since there is no 
explicit normative way to implement the widget object when the start file is 
SVG I had to decide on one. So I've added the following code in test.js:
  
  var w;

  if (typeof(window.widget) != undefined) {
w = window.widget;
  } else if (typeof(widget) != undefined) {
w = widget;
  }  


Is it ok?



I'm not sure what we will do with all the automatically generated
tests. We will need some guidance there from Dom, as I don't know how
that generator works.


So I'm wondering how should the widget object be implemented in a UA
that does not support the window object ?


Yeah, that's a tough one... the spec says:

For a widget instance, a user agent MUST expose a unique object that
implements the widget interface to author scripts.

It does not give any guidance as to how the interface must be exposed.

What was the rationale for having the widget object as an attribute of the 
window object. Why not put in the global object, this would avoid having to 
handle it differently in each language?

Cyril






--
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Mutimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France
http://concolato.blog.telecom-paristech.fr/
widget xmlns=http://www.w3.org/ns/widgets;
 id=test:au
 nameTest au/name
 descriptionTesting assertion ta-aa/description
 preference name=test1 value=abc123 /
 preference name=test2 value=protected readonly=true /
/widgetTitle: Test au


 
 
FAIL 
Test did not run. 
 attachment: index.svg

test.js
Description: JavaScript source


[widgets-twi] window object

2010-02-04 Thread Cyril Concolato

Hi all,

After PC, I'm looking now at the Widget Interface spec, in particular to check 
the test suite and produce the implementation report. I have a problem with the 
spec. In GPAC, we implement only SVG not HTML5, with the Window object. So I'm 
wondering how should the widget object be implemented in a UA that does not support 
the window object ?

Best regards,

Cyril
--
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Mutimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France
http://concolato.blog.telecom-paristech.fr/