Re: [whatwg] createEvent() in Web Workers?
On Thu, 26 Nov 2009, Simon Pieters wrote: There's ErrorEvent.initErrorEvent, and dispatchEvent is exposed in workers, but there's no createEvent (because there's no document). Are there use cases for sending events in a worker? Should we expose createEvent somewhere? Should we remove initErrorEvent? I don't want to remove initErrorEvent() because that would just cause troubles later if we ever add createEvent(). In the meantime, though, I don't see a really compelling reason to add event creation to the worker API set, so I haven't changed anything there for now. If DOM3 Events adds constructors or whatever, it can expose them to Workers easily enough. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] createEvent() in Web Workers?
On Fri, 27 Nov 2009 17:02:00 +0100, Simon Pieters sim...@opera.com wrote:
An idea for creating events is to support [Constructor] on all event
IDLs, which makes the createEvent method unnecessary.
Maybe we could even make the arguments to the constructor be called to
initFooEvent() directly, so instead of doing
var e = document.createEvent('MouseEvents');
e.initMouseEvent('click', ...);
foo.dispatchEvent(e);
you could do
foo.dispatchEvent(new MouseEvent('click', ...))
I've cc-ed www-dom since this is a suggestion for a change to DOM Events.
Another thing we could change is to make all but the first arguments to
initFooEvent() optional and let them have sensible defaults, so that if
all you care about is the event type, you can include just the first
argument.
If the constructor is called with no arguments, then initFooEvent() would
not be called.
--
Simon Pieters
Opera Software
Re: [whatwg] createEvent() in Web Workers?
I would like to see createEvent in WebWorker. My (theoretical) use case would involve using custom eventing to load or set new message handlers. Flow would be something like this window A creates worker 1 window A sends message to worker 1 worker 1 sends message to window A window A sends message to worker 1 worker 1 creates an event switch in response to message, passing the message in the event: createEvent(switch,message) worker 1 switch event handler loads / sets new message handler, mutating itself into worker 1 sub 1 and calls the new message handler on the passed message worker 1 sub 1 sends message to window A Anyone think this theoretical use case or some derivative is a useful abstraction to aid in code organization and flow control? I would think since an eventing queue is specified for message handling that adding custom events would not be much additional effort for implementers. initErrorEvent would seem to put the DOM Events Level 3 createEvent and initEvent methods together. Is there a reason that this approach was chosen instead of mirroring DOM Events? The simple answer seems to be because there is no DOM :) Regards, J5 Simon Pieters wrote: There's ErrorEvent.initErrorEvent, and dispatchEvent is exposed in workers, but there's no createEvent (because there's no document). Are there use cases for sending events in a worker? Should we expose createEvent somewhere? Should we remove initErrorEvent?
Re: [whatwg] createEvent() in Web Workers?
On Fri, 27 Nov 2009 16:50:21 +0100, Jonathan Cook
jonathan.j5.c...@gmail.com wrote:
Simon Pieters wrote:
There's ErrorEvent.initErrorEvent, and dispatchEvent is exposed in
workers, but there's no createEvent (because there's no document). Are
there use cases for sending events in a worker? Should we expose
createEvent somewhere? Should we remove initErrorEvent?
I would like to see createEvent in WebWorker. My (theoretical) use case
would involve using custom eventing to load or set new message
handlers. Flow would be something like this
window A creates worker 1
window A sends message to worker 1
worker 1 sends message to window A
window A sends message to worker 1
worker 1 creates an event switch in response to message, passing the
message in the event: createEvent(switch,message)
worker 1 switch event handler loads / sets new message handler, mutating
itself into worker 1 sub 1 and calls the new message handler on the
passed message
worker 1 sub 1 sends message to window A
Anyone think this theoretical use case or some derivative is a useful
abstraction to aid in code organization and flow control? I would think
since an eventing queue is specified for message handling that adding
custom events would not be much additional effort for implementers.
initErrorEvent would seem to put the DOM Events Level 3 createEvent and
initEvent methods together. Is there a reason that this approach was
chosen instead of mirroring DOM Events? The simple answer seems to be
because there is no DOM :)
An idea for creating events is to support [Constructor] on all event IDLs,
which makes the createEvent method unnecessary.
Maybe we could even make the arguments to the constructor be called to
initFooEvent() directly, so instead of doing
var e = document.createEvent('MouseEvents');
e.initMouseEvent('click', ...);
foo.dispatchEvent(e);
you could do
foo.dispatchEvent(new MouseEvent('click', ...))
I've cc-ed www-dom since this is a suggestion for a change to DOM Events.
--
Simon Pieters
Opera Software
Re: [whatwg] createEvent() in Web Workers?
An idea for creating events is to support [Constructor] on all event
IDLs, which makes the createEvent method unnecessary.
Maybe we could even make the arguments to the constructor be called to
initFooEvent() directly, so instead of doing
var e = document.createEvent('MouseEvents');
e.initMouseEvent('click', ...);
foo.dispatchEvent(e);
you could do
foo.dispatchEvent(new MouseEvent('click', ...))
I've cc-ed www-dom since this is a suggestion for a change to DOM Events.
I think that allowing creation of events via constructor is a good
idea. It is simple in a way that doesn't detract from usefulness. I
don't think it's a good idea to diverge far from how events are done in
the DOM for non-DOM uses. That means that the DOM specs should lead the
way in terms of providing for how events work for browsers, available
objects like Web Workers, server-side javascript and anything else you
can think of.
The DOM Level 3 Events spec is specifying interface DocumentEvent that
document should implement, corresponding to feature Events. It would
be nice if the DOM Level 3 DocumentEvent and Event interfaces were
super-classes of something also available for other implementations.
WorkerGlobalScope could implement this non-DOM eventing interface and
whatever constructors make sense to be available for Worker events
(ErrorEvent is the one that is already specified, as well as the
messaging ones). Another example of an object that does eventing but
isn't DOM is the XmlHttpRequest object.
Regards,
J5
I'm the type of person who thinks out loud and as such even in an
email conversation I can get long-winded and lengthily end up somewhere
that I later realize is much quicker to arrive at by direct means. I
don't know whether the protocol of this list is that I ramble or that I
be as direct as possible and do thinking off-list. I suspect that it
leans towards the latter and so I'm putting the rambling part below.
=
That uncouples events from the document object and makes it easier to
make them part of specs that are not DOM-related, so it sounds like a
good idea to me. I think you'd still want to support a no-arg
constructor and some form of mutators for initialization.
For use cases where separate initialization is not needed, I think the
syntax you're showing is very understandable and the terseness does not
detract from the usefulness.
For reasons related to use of reflection, it would still be nice to be
able to create an event by passing the name via string.
Could it make sense to have an independent event control object (factory
or singleton make sense to me) that could be used to create events via
reflection rather than explicit constructors? It might be interesting
to be able to look-ahead at upcoming events that are not yet being
processed, or have built in event history. Such an object could be a
window into existing eventing queues, as well as a place to implement a
createEvent method agnostically.
Under the hood the eventing object could be proxying to document or
workerglobalscope or window or whatever object or objects are actually
implementing eventing. In that sense I guess it could be made an
interface that document and workerglobalscope implement and not even be
a first-class object.
I am now thinking a bit in circles here, because I'm back to suggesting
document.createEvent() as just fine :) I hope my comments are useful.
I will try to summarize where I've ended up:
Objects implementing DOM Level 3 Event interface can be created via
constructor, equivalent to .creatEvent(foo), .initFooEvent(bar,baz,...)
EventingInterface specifies createEvent method and maybe some other fun
stuff for looking at eventing queues
Document (and possibly WorkerGlobalScope) to implement EventingInterface
(if people want the convenience of the coupling of Document with event
creation because of all the DOM Events)
Consider Eventing object eventing which implements EventingInterface
to be used in place of Document in non-DOM environments
Regards,
J5
[whatwg] createEvent() in Web Workers?
There's ErrorEvent.initErrorEvent, and dispatchEvent is exposed in workers, but there's no createEvent (because there's no document). Are there use cases for sending events in a worker? Should we expose createEvent somewhere? Should we remove initErrorEvent? -- Simon Pieters Opera Software
