[gwt-contrib] Re: Adding a DOM com.google.gwt.dom.client.Window class?
On 18-Aug-09, at 10:31 AM, Joel Webber wrote:
> One thing I didn't make clear from the beginning, btw, was that I
> *am* in favor of doing something about Window sooner rather than
> later, even if we don't resolve the rest of this stuff. More than
> anything, I wanted to get buy-in on the appropriate package/module,
> and the general approach for moving old APIs to new locations. See
> below for further comments.
No problem :). I think it makes a lot of sense to consider it as
part of a whole refactoring strategy like this.
> Then there's the question of how to move them in a sensibly
> backwards-compatible manner. With the DOM module's Element class, I
> kept the names the same, because they have to be typed so often. I'm
> still not 100% certain that was the best approach, but I guess it's
> worked ok. How weird would everyone find it if Window, Cookies,
> Timer, History, and DeferredCommand all showed up in two places,
> with the originals eventually deprecated? It makes me a little
> nervous, to be honest, but so does trying to come up with new names
> for all of them and confusing matters further.
>
> Our experience was pretty positive with the
> com.google.gwt.user.client.Element ->
> com.google.gwt.dom.client.Element mapping. Most of it was handled
> with a search and replace to fix up import statements. Assuming the
> function interface doesn't change dramatically (more like the
> element mapping than the event overhaul), it wouldn't be much of an
> issue, IMO.
>
> Here's the problem I see. With the user.Element -> dom.Element
> transition, I was basically able to move every non-stupid method
> more or less without modification, and not break existing code. The
> Window situation is much uglier. Because Java is stupid about not
> allowing static and instance methods of the same name, we can't just
> add instance methods to the existing Window class. So we'd end up
> with two unrelated Window classes, one with instance methods, and
> the other with statics.
>
> Kelly suggested using something like DOMWindow to break the tie,
> which has the nice quality of resembling the native webkit and gecko
> classes, but it's also a bit ugly (e.g.,
> DOMWindow.get().alert("foo")). As for Timer, we *could* explicitly
> model setTimeout() and setInterval() in DOMWindow, assuming that the
> timers have window-affinity (at least if it turns out they don't,
> nothing will go wrong).
An alternative structure would be adding two static get() methods: one
in the deprecated Window class and one in the new Window class. It
has the advantage of keeping the same developer-visible name. A
developer could begin the refactoring by replacing the static calls
with Window.get()-qualified calls. This would be sufficient to remove
the deprecation warnings - no more action would be required on the
developer's part, at least until the Window class itself were
deprecated:
package com.google.gwt.user.client;
public class Window {
public com.google.gwt.dom.client.Window.get() {
return $wnd;
}
@Deprecated
public void alert() {
get().alert();
}
}
package com.google.gwt.dom.client;
public class Window {
public Window get() {
return $wnd;
}
public void alert() {
this.alert();
}
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Adding a DOM com.google.gwt.dom.client.Window class?
One thing I didn't make clear from the beginning, btw, was that I *am* in
favor of doing something about Window sooner rather than later, even if we
don't resolve the rest of this stuff. More than anything, I wanted to get
buy-in on the appropriate package/module, and the general approach for
moving old APIs to new locations. See below for further comments.
On Mon, Aug 17, 2009 at 2:16 PM, Matt Mastracci wrote:
> Joel,
>
> This is definitely a can of worms! I spent some time thinking through the
> some of these points. Some additional comments inline...
>
> On 17-Aug-09, at 10:02 AM, Joel Webber wrote:
>
>>
>> At any rate, we *do* need something like this, and now seems as good a
>> time as any to bring it up. In fact, there are several such classes that
>> need to be moved out of gwt.user.client into a more sensible place (and
>> others that still need to be written). What they have in common is that they
>> have nothing to do with widgets, but are not "core" because they assume the
>> existence of a real web browser (as opposed to other potential Javascript
>> targets such as Flash). The ones that come to mind are:
>>
>
> Existing:
>> - Window
>> - Location
>> - Cookies (though maybe Document just needs its cookie property
>> implemented)
>> - Timer (this is implemented on top of Window.set[Interval Timeout]())
>> - History (there are both the native "history" object, and the GWT history
>> implementation to consider)
>> - [Incremental Deferred]Command (Smells like core, but requires Timer to
>> work)
>>
>
> One consideration this raises is that some have internal state associated
> with them. For instance, both the Cookies class and Location classes have
> precomputed maps of data. How can you ensure that a service is a singleton
> for a given native object (or is it best to provide this for the default
> window and document only)? There's also the issue with cleaning up objects
> when documents/windows are unloaded, since the lifetime of the GWT module
> may be significantly longer than the windows it references. I suppose the
> cleanup could be handled via some global per-window unload cleanup queue
> attached to a specific window's unload handler.
>
> Additionally, how can you handle multiple GWT modules that may reference
> the same native window or document?
>
> History and location may be useful to expose as simple JSO wrappers over
> the native browser's objects. The full GWT history implementation would
> probably be less useful on a window that didn't contain a GWT module (esp.
> considering that newItem() is so different on every browser).
>
My inclination would be to avoid the caching stuff for the core browser
APIs, for precisely the reasons you point out. History is a big question
mark, but could easily be avoided for the time being (though it *does* at
least belong in its own module, but that's a separate issue).
For Timer and IncrementalCommand, I suspect there wouldn't be much lost if
> they were left as global services. The only advantage to having per-window
> timers that I can think of right now would be scoping the lifetime of the
> timer to the window itself (is this even consistent across browsers?). I
> think it might be sufficient to create a rebind point for creating timers
> for different environments. FWIW, this is the code we use to simulate Timer
> when running as a Firefox extension. It would be a lot cleaner as a timer
> rebind and I imagine that AIR and other JS-but-not-HTML environments would
> be very similar:
>
>window.setTimeout = function(callback, timeout) {
>var timer = Components.classes["@mozilla.org/timer
> ;1"].createInstance(Components.interfaces.nsITimer);
>var handle = {timer: timer, active: 1, callback: callback};
>
>var doNotify = function() {
>manag...@com.dotspots.mozilla.extensionmanager
> ::activeOneShotTimers--;
>delete handle.active;
>delete handle.callback;
>delete handle.timer;
>manag...@com.dotspots.mozilla.extensionmanager
> ::safeCallback(Lcom/google/gwt/core/client/JavaScriptObject;)(callback);
>}
>
>timer.initWithCallback({notify: doNotify}, timeout,
> Components.interfaces.nsITimer.TYPE_ONE_SHOT);
>manag...@com.dotspots.mozilla.extensionmanager
> ::activeOneShotTimers++;
>
>timers.push(handle);
>return timers.length - 1;
>}
>
> New:
>> - Selection (this is pretty tricky, because selection on IE is so
>> amazingly weird)
>> - Others?
>>
>
> Selection would be very useful, even if it was limited to some simple
> operations at first (exists, get text, delete, replace). The W3C selection
> API is very useful, but I'm not sure if there's a compelling use case
> outside of Google Wave to merit the effort required (I had experimented with
> this a while back, but it's diff
[gwt-contrib] Re: Adding a DOM com.google.gwt.dom.client.Window class?
@mP: That would be great if you're interested in moving it into GWT proper.
It's one of those things we've always known was a big can of worms, and no
one's had much time to look into it.
On Mon, Aug 17, 2009 at 5:30 PM, Miroslav Pokorny <
miroslav.poko...@gmail.com> wrote:
> Re/ Selections
>
> I have Selections for all the big 4 in my library. Ive implemrmted most of
> the needed functionality to mimic the w3c interfaces including:
>
> • creation by specifying end points ( Elements, offset)
> • testing if a selection exists.
> • expanding / moving either the start / end.
> • deletion
> • clearing a selection.
> • extracting a selection (the cut so it can be "pasted" somewhere else).
> • surrounding - inserting a parent making it easy to add a span with
> styling.
> • enabling/ disabling selection for a dom fragment.
> • retrieve selected text
>
> Most of what you need is there. I might be wrong but if memory serves me
> tight i could not defeat the way Ie rounds selections to the nearest whole
> word once they grow bigger than a minimal size.
>
> This is all 1.5 compatible code but it should be no big deal to sex it up
> if interest exists in taking it.
>
> Hth
>
>
> On 18/08/2009, at 4:16 AM, Matt Mastracci wrote:
>
>
>> Joel,
>>
>> This is definitely a can of worms! I spent some time thinking through
>> the some of these points. Some additional comments inline...
>>
>> On 17-Aug-09, at 10:02 AM, Joel Webber wrote:
>>
>>>
>>> At any rate, we *do* need something like this, and now seems as good
>>> a time as any to bring it up. In fact, there are several such
>>> classes that need to be moved out of gwt.user.client into a more
>>> sensible place (and others that still need to be written). What they
>>> have in common is that they have nothing to do with widgets, but are
>>> not "core" because they assume the existence of a real web browser
>>> (as opposed to other potential Javascript targets such as Flash).
>>> The ones that come to mind are:
>>>
>>
>> Existing:
>>> - Window
>>> - Location
>>> - Cookies (though maybe Document just needs its cookie property
>>> implemented)
>>> - Timer (this is implemented on top of Window.set[Interval Timeout]())
>>> - History (there are both the native "history" object, and the GWT
>>> history implementation to consider)
>>> - [Incremental Deferred]Command (Smells like core, but requires
>>> Timer to work)
>>>
>>
>> One consideration this raises is that some have internal state
>> associated with them. For instance, both the Cookies class and
>> Location classes have precomputed maps of data. How can you ensure
>> that a service is a singleton for a given native object (or is it best
>> to provide this for the default window and document only)? There's
>> also the issue with cleaning up objects when documents/windows are
>> unloaded, since the lifetime of the GWT module may be significantly
>> longer than the windows it references. I suppose the cleanup could be
>> handled via some global per-window unload cleanup queue attached to a
>> specific window's unload handler.
>>
>> Additionally, how can you handle multiple GWT modules that may
>> reference the same native window or document?
>>
>> History and location may be useful to expose as simple JSO wrappers
>> over the native browser's objects. The full GWT history
>> implementation would probably be less useful on a window that didn't
>> contain a GWT module (esp. considering that newItem() is so different
>> on every browser).
>>
>> For Timer and IncrementalCommand, I suspect there wouldn't be much
>> lost if they were left as global services. The only advantage to
>> having per-window timers that I can think of right now would be
>> scoping the lifetime of the timer to the window itself (is this even
>> consistent across browsers?). I think it might be sufficient to
>> create a rebind point for creating timers for different environments.
>> FWIW, this is the code we use to simulate Timer when running as a
>> Firefox extension. It would be a lot cleaner as a timer rebind and I
>> imagine that AIR and other JS-but-not-HTML environments would be very
>> similar:
>>
>> window.setTimeout = function(callback, timeout) {
>> var timer = Components.classes["@mozilla.org/timer;
>> 1"].createInstance(Components.interfaces.nsITimer);
>> var handle = {timer: timer, active: 1, callback: callback};
>>
>> var doNotify = function() {
>>
>> manag...@com.dotspots.mozilla.extensionmanager::activeOneShotTimers--;
>> delete handle.active;
>> delete handle.callback;
>> delete handle.timer;
>> manag...@com.dotspots.mozilla.extensionmanager
>> ::safeCallback(Lcom/
>> google/gwt/core/client/JavaScriptObject;)(callback);
>> }
>>
>> timer.initWithCallback({notify: doNotify}, timeout,
>> Components.interfaces.nsITimer.TYPE_ONE_SHOT);
>> manag...@com.dotspots.mozilla.extensionmanager
>> ::activeOneShotTimers++;
>>
>> timers.push(handle);
>> ret
[gwt-contrib] Re: Adding a DOM com.google.gwt.dom.client.Window class?
One thing I didn't make clear from the beginning, btw, was that I *am* in
favor of doing something about Window sooner rather than later, even if we
don't resolve the rest of this stuff. More than anything, I wanted to get
buy-in on the appropriate package/module, and the general approach for
moving old APIs to new locations. See below for further comments.
On Mon, Aug 17, 2009 at 2:16 PM, Matt Mastracci wrote:
> Joel,
>
> This is definitely a can of worms! I spent some time thinking through the
> some of these points. Some additional comments inline...
>
> On 17-Aug-09, at 10:02 AM, Joel Webber wrote:
>
>>
>> At any rate, we *do* need something like this, and now seems as good a
>> time as any to bring it up. In fact, there are several such classes that
>> need to be moved out of gwt.user.client into a more sensible place (and
>> others that still need to be written). What they have in common is that they
>> have nothing to do with widgets, but are not "core" because they assume the
>> existence of a real web browser (as opposed to other potential Javascript
>> targets such as Flash). The ones that come to mind are:
>>
>
> Existing:
>> - Window
>> - Location
>> - Cookies (though maybe Document just needs its cookie property
>> implemented)
>> - Timer (this is implemented on top of Window.set[Interval Timeout]())
>> - History (there are both the native "history" object, and the GWT history
>> implementation to consider)
>> - [Incremental Deferred]Command (Smells like core, but requires Timer to
>> work)
>>
>
> One consideration this raises is that some have internal state associated
> with them. For instance, both the Cookies class and Location classes have
> precomputed maps of data. How can you ensure that a service is a singleton
> for a given native object (or is it best to provide this for the default
> window and document only)? There's also the issue with cleaning up objects
> when documents/windows are unloaded, since the lifetime of the GWT module
> may be significantly longer than the windows it references. I suppose the
> cleanup could be handled via some global per-window unload cleanup queue
> attached to a specific window's unload handler.
>
> Additionally, how can you handle multiple GWT modules that may reference
> the same native window or document?
>
> History and location may be useful to expose as simple JSO wrappers over
> the native browser's objects. The full GWT history implementation would
> probably be less useful on a window that didn't contain a GWT module (esp.
> considering that newItem() is so different on every browser).
>
My inclination would be to avoid the caching stuff for the core browser
APIs, for precisely the reasons you point out. History is a big question
mark, but could easily be avoided for the time being (though it *does* at
least belong in its own module, but that's a separate issue).
For Timer and IncrementalCommand, I suspect there wouldn't be much lost if
> they were left as global services. The only advantage to having per-window
> timers that I can think of right now would be scoping the lifetime of the
> timer to the window itself (is this even consistent across browsers?). I
> think it might be sufficient to create a rebind point for creating timers
> for different environments. FWIW, this is the code we use to simulate Timer
> when running as a Firefox extension. It would be a lot cleaner as a timer
> rebind and I imagine that AIR and other JS-but-not-HTML environments would
> be very similar:
>
>window.setTimeout = function(callback, timeout) {
>var timer = Components.classes["@mozilla.org/timer
> ;1"].createInstance(Components.interfaces.nsITimer);
>var handle = {timer: timer, active: 1, callback: callback};
>
>var doNotify = function() {
>manag...@com.dotspots.mozilla.extensionmanager
> ::activeOneShotTimers--;
>delete handle.active;
>delete handle.callback;
>delete handle.timer;
>manag...@com.dotspots.mozilla.extensionmanager
> ::safeCallback(Lcom/google/gwt/core/client/JavaScriptObject;)(callback);
>}
>
>timer.initWithCallback({notify: doNotify}, timeout,
> Components.interfaces.nsITimer.TYPE_ONE_SHOT);
>manag...@com.dotspots.mozilla.extensionmanager
> ::activeOneShotTimers++;
>
>timers.push(handle);
>return timers.length - 1;
>}
>
> New:
>> - Selection (this is pretty tricky, because selection on IE is so
>> amazingly weird)
>> - Others?
>>
>
> Selection would be very useful, even if it was limited to some simple
> operations at first (exists, get text, delete, replace). The W3C selection
> API is very useful, but I'm not sure if there's a compelling use case
> outside of Google Wave to merit the effort required (I had experimented with
> this a while back, but it's diff
[gwt-contrib] Re: Adding a DOM com.google.gwt.dom.client.Window class?
Re/ Selections
I have Selections for all the big 4 in my library. Ive implemrmted
most of the needed functionality to mimic the w3c interfaces including:
• creation by specifying end points ( Elements, offset)
• testing if a selection exists.
• expanding / moving either the start / end.
• deletion
• clearing a selection.
• extracting a selection (the cut so it can be "pasted" somewhere
else).
• surrounding - inserting a parent making it easy to add a span with
styling.
• enabling/ disabling selection for a dom fragment.
• retrieve selected text
Most of what you need is there. I might be wrong but if memory serves
me tight i could not defeat the way Ie rounds selections to the
nearest whole word once they grow bigger than a minimal size.
This is all 1.5 compatible code but it should be no big deal to sex it
up if interest exists in taking it.
Hth
On 18/08/2009, at 4:16 AM, Matt Mastracci wrote:
>
> Joel,
>
> This is definitely a can of worms! I spent some time thinking through
> the some of these points. Some additional comments inline...
>
> On 17-Aug-09, at 10:02 AM, Joel Webber wrote:
>>
>> At any rate, we *do* need something like this, and now seems as good
>> a time as any to bring it up. In fact, there are several such
>> classes that need to be moved out of gwt.user.client into a more
>> sensible place (and others that still need to be written). What they
>> have in common is that they have nothing to do with widgets, but are
>> not "core" because they assume the existence of a real web browser
>> (as opposed to other potential Javascript targets such as Flash).
>> The ones that come to mind are:
>
>> Existing:
>> - Window
>> - Location
>> - Cookies (though maybe Document just needs its cookie property
>> implemented)
>> - Timer (this is implemented on top of Window.set[Interval Timeout]
>> ())
>> - History (there are both the native "history" object, and the GWT
>> history implementation to consider)
>> - [Incremental Deferred]Command (Smells like core, but requires
>> Timer to work)
>
> One consideration this raises is that some have internal state
> associated with them. For instance, both the Cookies class and
> Location classes have precomputed maps of data. How can you ensure
> that a service is a singleton for a given native object (or is it best
> to provide this for the default window and document only)? There's
> also the issue with cleaning up objects when documents/windows are
> unloaded, since the lifetime of the GWT module may be significantly
> longer than the windows it references. I suppose the cleanup could be
> handled via some global per-window unload cleanup queue attached to a
> specific window's unload handler.
>
> Additionally, how can you handle multiple GWT modules that may
> reference the same native window or document?
>
> History and location may be useful to expose as simple JSO wrappers
> over the native browser's objects. The full GWT history
> implementation would probably be less useful on a window that didn't
> contain a GWT module (esp. considering that newItem() is so different
> on every browser).
>
> For Timer and IncrementalCommand, I suspect there wouldn't be much
> lost if they were left as global services. The only advantage to
> having per-window timers that I can think of right now would be
> scoping the lifetime of the timer to the window itself (is this even
> consistent across browsers?). I think it might be sufficient to
> create a rebind point for creating timers for different environments.
> FWIW, this is the code we use to simulate Timer when running as a
> Firefox extension. It would be a lot cleaner as a timer rebind and I
> imagine that AIR and other JS-but-not-HTML environments would be very
> similar:
>
>window.setTimeout = function(callback, timeout) {
>var timer = Components.classes["@mozilla.org/timer;
> 1"].createInstance(Components.interfaces.nsITimer);
>var handle = {timer: timer, active: 1, callback: callback};
>
>var doNotify = function() {
>
> manag...@com.dotspots.mozilla.extensionmanager::activeOneShotTimers--;
>delete handle.active;
>delete handle.callback;
>delete handle.timer;
>
> manag...@com.dotspots.mozilla.extensionmanager::safeCallback(Lcom/
> google/gwt/core/client/JavaScriptObject;)(callback);
>}
>
>timer.initWithCallback({notify: doNotify}, timeout,
> Components.interfaces.nsITimer.TYPE_ONE_SHOT);
>
> manag...@com.dotspots.mozilla.extensionmanager::activeOneShotTimers++;
>
>timers.push(handle);
>return timers.length - 1;
>}
>
>> New:
>> - Selection (this is pretty tricky, because selection on IE is so
>> amazingly weird)
>> - Others?
>
> Selection would be very useful, even if it was limited to some simple
> operations at first (exists, get text, delete, replace). The W3C
> selection API is very useful, but I'm not sure if there's a compelling
> use case outside of Google
[gwt-contrib] Re: Adding a DOM com.google.gwt.dom.client.Window class?
Additionally, DOM overlay types could be generalized with JSO Single
Impl interfaces.
On 17 ago, 15:16, Matt Mastracci wrote:
> Joel,
>
> This is definitely a can of worms! I spent some time thinking through
> the some of these points. Some additional comments inline...
>
> On 17-Aug-09, at 10:02 AM, Joel Webber wrote:
>
>
>
>
>
> > At any rate, we *do* need something like this, and now seems as good
> > a time as any to bring it up. In fact, there are several such
> > classes that need to be moved out of gwt.user.client into a more
> > sensible place (and others that still need to be written). What they
> > have in common is that they have nothing to do with widgets, but are
> > not "core" because they assume the existence of a real web browser
> > (as opposed to other potential Javascript targets such as Flash).
> > The ones that come to mind are:
> > Existing:
> > - Window
> > - Location
> > - Cookies (though maybe Document just needs its cookie property
> > implemented)
> > - Timer (this is implemented on top of Window.set[Interval Timeout]())
> > - History (there are both the native "history" object, and the GWT
> > history implementation to consider)
> > - [Incremental Deferred]Command (Smells like core, but requires
> > Timer to work)
>
> One consideration this raises is that some have internal state
> associated with them. For instance, both the Cookies class and
> Location classes have precomputed maps of data. How can you ensure
> that a service is a singleton for a given native object (or is it best
> to provide this for the default window and document only)? There's
> also the issue with cleaning up objects when documents/windows are
> unloaded, since the lifetime of the GWT module may be significantly
> longer than the windows it references. I suppose the cleanup could be
> handled via some global per-window unload cleanup queue attached to a
> specific window's unload handler.
>
> Additionally, how can you handle multiple GWT modules that may
> reference the same native window or document?
>
> History and location may be useful to expose as simple JSO wrappers
> over the native browser's objects. The full GWT history
> implementation would probably be less useful on a window that didn't
> contain a GWT module (esp. considering that newItem() is so different
> on every browser).
>
> For Timer and IncrementalCommand, I suspect there wouldn't be much
> lost if they were left as global services. The only advantage to
> having per-window timers that I can think of right now would be
> scoping the lifetime of the timer to the window itself (is this even
> consistent across browsers?). I think it might be sufficient to
> create a rebind point for creating timers for different environments.
> FWIW, this is the code we use to simulate Timer when running as a
> Firefox extension. It would be a lot cleaner as a timer rebind and I
> imagine that AIR and other JS-but-not-HTML environments would be very
> similar:
>
> window.setTimeout = function(callback, timeout) {
> var timer = Components.classes["@mozilla.org/timer;
> 1"].createInstance(Components.interfaces.nsITimer);
> var handle = {timer: timer, active: 1, callback: callback};
>
> var doNotify = function() {
>
> manag...@com.dotspots.mozilla.extensionmanager::activeOneShotTimers--;
> delete handle.active;
> delete handle.callback;
> delete handle.timer;
>
> manag...@com.dotspots.mozilla.extensionmanager::safeCallback(Lcom/
> google/gwt/core/client/JavaScriptObject;)(callback);
> }
>
> timer.initWithCallback({notify: doNotify}, timeout,
> Components.interfaces.nsITimer.TYPE_ONE_SHOT);
>
> manag...@com.dotspots.mozilla.extensionmanager::activeOneShotTimers++;
>
> timers.push(handle);
> return timers.length - 1;
> }
>
> > New:
> > - Selection (this is pretty tricky, because selection on IE is so
> > amazingly weird)
> > - Others?
>
> Selection would be very useful, even if it was limited to some simple
> operations at first (exists, get text, delete, replace). The W3C
> selection API is very useful, but I'm not sure if there's a compelling
> use case outside of Google Wave to merit the effort required (I had
> experimented with this a while back, but it's difficult to get
> consistent results between webkit/gecko, let alone with IE in the
> picture :)!).
>
> There's a few miscellaneous DOM services that would be useful, such as
> the DOM tree walking service and xpath functions. Neither of those is
> complex enough to be consequential, so they probably wouldn't factor
> into any design.
>
>
>
> > The main hold up for me has been figuring out how to move the
> > existing classes to a more sensible module, and p
[gwt-contrib] Re: Adding a DOM com.google.gwt.dom.client.Window class?
Joel,
This is definitely a can of worms! I spent some time thinking through
the some of these points. Some additional comments inline...
On 17-Aug-09, at 10:02 AM, Joel Webber wrote:
>
> At any rate, we *do* need something like this, and now seems as good
> a time as any to bring it up. In fact, there are several such
> classes that need to be moved out of gwt.user.client into a more
> sensible place (and others that still need to be written). What they
> have in common is that they have nothing to do with widgets, but are
> not "core" because they assume the existence of a real web browser
> (as opposed to other potential Javascript targets such as Flash).
> The ones that come to mind are:
> Existing:
> - Window
> - Location
> - Cookies (though maybe Document just needs its cookie property
> implemented)
> - Timer (this is implemented on top of Window.set[Interval Timeout]())
> - History (there are both the native "history" object, and the GWT
> history implementation to consider)
> - [Incremental Deferred]Command (Smells like core, but requires
> Timer to work)
One consideration this raises is that some have internal state
associated with them. For instance, both the Cookies class and
Location classes have precomputed maps of data. How can you ensure
that a service is a singleton for a given native object (or is it best
to provide this for the default window and document only)? There's
also the issue with cleaning up objects when documents/windows are
unloaded, since the lifetime of the GWT module may be significantly
longer than the windows it references. I suppose the cleanup could be
handled via some global per-window unload cleanup queue attached to a
specific window's unload handler.
Additionally, how can you handle multiple GWT modules that may
reference the same native window or document?
History and location may be useful to expose as simple JSO wrappers
over the native browser's objects. The full GWT history
implementation would probably be less useful on a window that didn't
contain a GWT module (esp. considering that newItem() is so different
on every browser).
For Timer and IncrementalCommand, I suspect there wouldn't be much
lost if they were left as global services. The only advantage to
having per-window timers that I can think of right now would be
scoping the lifetime of the timer to the window itself (is this even
consistent across browsers?). I think it might be sufficient to
create a rebind point for creating timers for different environments.
FWIW, this is the code we use to simulate Timer when running as a
Firefox extension. It would be a lot cleaner as a timer rebind and I
imagine that AIR and other JS-but-not-HTML environments would be very
similar:
window.setTimeout = function(callback, timeout) {
var timer = Components.classes["@mozilla.org/timer;
1"].createInstance(Components.interfaces.nsITimer);
var handle = {timer: timer, active: 1, callback: callback};
var doNotify = function() {
manag...@com.dotspots.mozilla.extensionmanager::activeOneShotTimers--;
delete handle.active;
delete handle.callback;
delete handle.timer;
manag...@com.dotspots.mozilla.extensionmanager::safeCallback(Lcom/
google/gwt/core/client/JavaScriptObject;)(callback);
}
timer.initWithCallback({notify: doNotify}, timeout,
Components.interfaces.nsITimer.TYPE_ONE_SHOT);
manag...@com.dotspots.mozilla.extensionmanager::activeOneShotTimers++;
timers.push(handle);
return timers.length - 1;
}
> New:
> - Selection (this is pretty tricky, because selection on IE is so
> amazingly weird)
> - Others?
Selection would be very useful, even if it was limited to some simple
operations at first (exists, get text, delete, replace). The W3C
selection API is very useful, but I'm not sure if there's a compelling
use case outside of Google Wave to merit the effort required (I had
experimented with this a while back, but it's difficult to get
consistent results between webkit/gecko, let alone with IE in the
picture :)!).
There's a few miscellaneous DOM services that would be useful, such as
the DOM tree walking service and xpath functions. Neither of those is
complex enough to be consequential, so they probably wouldn't factor
into any design.
>
> The main hold up for me has been figuring out how to move the
> existing classes to a more sensible module, and precisely what that
> module is. Selection and Window could arguably be considered par of
> DOM (WebKit has a DOMWindow class, even though the W3C doesn't
> consider it part of the DOM per se). It is not immediately obvious
> to me where the others should live, though -- should we have a
[gwt-contrib] Re: Adding a DOM com.google.gwt.dom.client.Window class?
Matt, Thanks for bringing this up; I've been meaning to do so for a long time. When the original Window class was written, it was basically infeasible to support multiple-window code in GWT, and JavaScriptObject was opaque and non-extensible. Such are the problems of writing libraries against rapidly-evolving compiler tech :) At any rate, we *do* need something like this, and now seems as good a time as any to bring it up. In fact, there are several such classes that need to be moved out of gwt.user.client into a more sensible place (and others that still need to be written). What they have in common is that they have nothing to do with widgets, but are not "core" because they assume the existence of a real web browser (as opposed to other potential Javascript targets such as Flash). The ones that come to mind are: Existing: - Window - Location - Cookies (though maybe Document just needs its cookie property implemented) - Timer (this is implemented on top of Window.set[Interval Timeout]()) - History (there are both the native "history" object, and the GWT history implementation to consider) - [Incremental Deferred]Command (Smells like core, but requires Timer to work) New: - Selection (this is pretty tricky, because selection on IE is so amazingly weird) - Others? The main hold up for me has been figuring out how to move the existing classes to a more sensible module, and precisely what that module is. Selection and Window could arguably be considered par of DOM (WebKit has a DOMWindow class, even though the W3C doesn't consider it part of the DOM per se). It is not immediately obvious to me where the others should live, though -- should we have a Browser module, for example? Then there's the question of how to move them in a sensibly backwards-compatible manner. With the DOM module's Element class, I kept the names the same, because they have to be typed so often. I'm still not 100% certain that was the best approach, but I guess it's worked ok. How weird would everyone find it if Window, Cookies, Timer, History, and DeferredCommand all showed up in two places, with the originals eventually deprecated? It makes me a little nervous, to be honest, but so does trying to come up with new names for all of them and confusing matters further. Cheers, joel. On Thu, Aug 13, 2009 at 2:45 PM, Matt Mastracci wrote: > > Hi all, > > I've been hacking around the lack of a true JavaScriptObject window in > GWT for a while and I was wondering if there was any interest in me > providing a patch for it. While the current > com.google.gwt.user.client.Window works for most cases, you aren't > able to interact with other windows in the system without resorting to > hand-rolled JSNI. For example, calling > com.google.gwt.user.client.Window::open() doesn't provide you a way to > close the window that was just opened. > > I propose adding a JSO subclass to the com.google.gwt.dom.client > package. For the first patch there would be a handful of > uncontroversial methods on it (further patches could provide the > remainder of the functionality that exists in the > com.google.gwt.user.client.Window): > > Document getDocument(); > void alert(String); > String prompt(String); > void close(); > > I would also propose adding the following method to Document to get > its associated window. On standards-compliant browsers, this would > map to "defaultView". On IE, this would map to "parentWindow": > > Window getParentWindow() > > Thoughts? > > Matt. > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
