[gwt-contrib] Re: wrapping existing element too restrictive maybe....
To reiterate: - RootPanel.detachOnWindowClose() must be called for all widgets that have no parents. - This is implicitly called by Widgets' wrap() methods and RootPanel.get(id). - All widgets for which this method is called will remain marked as 'attached' until RootPanel.detachNow() is called. - If a widget attached in this way has its element detached from the DOM, implicitly or explicitly, you *must* call RootPanel.detachNow(). - There is no way for GWT to know that you've done this, because the browser doesn't provide this notification. - If the assertion in RootPanel.detachWidgets() fails, that means that a widget was found in the detach list that is *not* attached to the DOM. This proves that the element was detached without its Widget being passed to RootPanel.detachNow(). This code cannot realistically know about your DOM structure, so if you do something like this: div id='outer' button id='inner'/ / html = HTML.wrap(Document.get().getElementById(outer)); button = Button.wrap(Document.get().getElementById(inner)); html.setInnerHTML(Look, I just nuked the button widget!); You still have to call detachNow() for the inner button widget. Despite the fact that the outer HTML widget appears to contain the Button widget, there's still no parent-child hierarchy at the widget level. Honestly, I would prefer to assert up front that this sort of implicit parent-child relationship among 'root' widgets not be created in the first place, but that's pretty tricky, and I don't believe it could be resilient to arbitrary DOM trickery anyway. Cheers, joel. On Tue, Sep 23, 2008 at 10:32 AM, Ed [EMAIL PROTECTED] wrote: Thanks again for your answer. Let me see if I understand you completely. If you are going to be removing existing RootPanels from the DOM implicitly (i.e. by removing one of their parent elements), you're going to have to call RootPanel.detachNow() on them. By removing you mean, physical removing it from the DOM without detaching it? Calling widget.onDetach() is enough for overcoming this orphan problems? Is so, why does the assertion not take that into account? I mean, in my case I switch the original content for some other HTML widget, like: stuff.clear(); stuff.add(otherWidget); In the clear() method it will remove the HTML widget that contains the RootPanels, such that it will properly detach all his children and as such the RootPanels. Shouldn't a RootPanel override the onDetach() method and then remove itself form the widgetsToDetach list? Isn't this what happens when calling RootPanel.detachNow(theRootPanel)? such that it can be automatically done in the onDetach() method in RootPanel. I think I am missing something :(.. Please some more details if possible, or a tinny example? I understand that a Widget should be attached to the Document body to be removed properly, but I don't understand the Assertion. Even do you signal in the Assertion that he isn't attached to the Body, you are calling onDetach() anyway, so I would say it's not important anymore, he is properly detached anyway (just like what happens in RootPanel.detachNow() ), so what's the point of this Assertion? :( -- Ed On Sep 23, 3:33 pm, Joel Webber [EMAIL PROTECTED] wrote: If you are going to be removing existing RootPanels from the DOM implicitly (i.e. by removing one of their parent elements), you're going to have to call RootPanel.detachNow() on them. The reason this is necessary is that otherwise they will be orphaned, meaning that they're out of the DOM, but neither they nor their child widgets are aware of having been removed. This can break a number of things, including potentially creating leaks. That's also why the assertion in detachWidgets() is necessary -- I would prefer to be able to throw an exception when the problem is created (i.e. when the parent element is removed from the DOM), but there's no way to receive notification of this. On Mon, Sep 22, 2008 at 4:57 PM, Ed [EMAIL PROTECTED] wrote: He Joel, Just a tinny problem I am still stuck with: In your example above, the replaced content, contains a few more RootPanels like this: ... div id='stuff' ... stuff ... div id='rootPanela' div id='rootPanelb' /div ... What I do: replacing the content of id=stuff with some HTML widget when the user presses a button, like you describe above. When the user clicks another button, I put back the original content. However, the original content contains some html snippets that are loaded with a RootPanel (for example to add some Form). If the user clicks a button such that the original content is replaced, such that the RootPanels are put aside and not attached to the body, the new code (I think it's even your code ;)) in RootPanel: detachWidgets will throw an Assert exception when the hosted browser is refreshed at that moment, as these
[gwt-contrib] Re: Code Review: Gadget RPC demo (it works!)
LGTM just a couple of nits below. On Fri, Sep 5, 2008 at 1:52 PM, Eric Ayers [EMAIL PROTECTED] wrote: A samples/gadgetrpc/src/com/google/gwt/gadgets/sample/gadgetrpc/server/GadgetRPCServlet.java Nit: Add @SuppressWarning(serial). Did you intend to have the servletStartTime field be static? Would instance final be better? A samples/gadgetrpc/src/com/google/gwt/gadgets/sample/gadgetrpc/client/ServerInfo.java Nits: accessor methods? Add @SuppressWarning(serial) A samples/gadgetrpc/src/com/google/gwt/gadgets/sample/gadgetrpc/public/GadgetRPC.html Nit: do you need this file? -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review: Gadget RPC demo (it works!)
Committed as r853 and r854. Thanks for the review. On Wed, Sep 24, 2008 at 9:59 AM, Miguel Méndez [EMAIL PROTECTED] wrote: LGTM just a couple of nits below. On Fri, Sep 5, 2008 at 1:52 PM, Eric Ayers [EMAIL PROTECTED] wrote: A samples/gadgetrpc/src/com/google/gwt/gadgets/sample/gadgetrpc/server/GadgetRPCServlet.java Nit: Add @SuppressWarning(serial). Did you intend to have the servletStartTime field be static? Would instance final be better? I wanted a value that wouldn't change between RPCs, but would change if the server was restarted (code might be updated). I think that both would accomplish that, but the instance final might change without a reload, which could be confusing. A samples/gadgetrpc/src/com/google/gwt/gadgets/sample/gadgetrpc/client/ServerInfo.java Nits: accessor methods? Add @SuppressWarning(serial) added. A samples/gadgetrpc/src/com/google/gwt/gadgets/sample/gadgetrpc/public/GadgetRPC.html Nit: do you need this file? It is used by the GadgetsRPC-shell startup file so that it doesn't just come up with an error or a blank screen. Except for that the reference might have been missing from GadgetsRPC-shell, which I just added. -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review: Gadget RPC demo (it works!)
It all sounds good to me. On Wed, Sep 24, 2008 at 11:34 AM, Eric Ayers [EMAIL PROTECTED] wrote: Committed as r853 and r854. Thanks for the review. On Wed, Sep 24, 2008 at 9:59 AM, Miguel Méndez [EMAIL PROTECTED] wrote: LGTM just a couple of nits below. On Fri, Sep 5, 2008 at 1:52 PM, Eric Ayers [EMAIL PROTECTED] wrote: A samples/gadgetrpc/src/com/google/gwt/gadgets/sample/gadgetrpc/server/GadgetRPCServlet.java Nit: Add @SuppressWarning(serial). Did you intend to have the servletStartTime field be static? Would instance final be better? I wanted a value that wouldn't change between RPCs, but would change if the server was restarted (code might be updated). I think that both would accomplish that, but the instance final might change without a reload, which could be confusing. A samples/gadgetrpc/src/com/google/gwt/gadgets/sample/gadgetrpc/client/ServerInfo.java Nits: accessor methods? Add @SuppressWarning(serial) added. A samples/gadgetrpc/src/com/google/gwt/gadgets/sample/gadgetrpc/public/GadgetRPC.html Nit: do you need this file? It is used by the GadgetsRPC-shell startup file so that it doesn't just come up with an error or a blank screen. Except for that the reference might have been missing from GadgetsRPC-shell, which I just added. -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ -- Miguel --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Story of Your Compile - initial AST work and demo reports
Changes from previous patch: - SourceInfos are now created only via JProgram and JsProgram. Descendant collection is now a field in the program types. - Optimized getRoots() call in SourceInfo - Addressed nits SourceInfo is now an abstract class with a protected constructor. Each AST package has its own SourceInfo subtype with package-protected constructors to ensure that only the relevant program type constructs SourceInfo objects. Also, as we expand the type of data that's collected, I expect to add additional, per-AST, information to the subtypes. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- soyc_r3676.patch.gz Description: GNU Zip compressed data
[gwt-contrib] Re: RR : Story of Your Compile - initial AST work and demo reports
On Wed, Sep 24, 2008 at 11:53 AM, BobV [EMAIL PROTECTED] wrote: SourceInfo is now an abstract class with a protected constructor. Each AST package has its own SourceInfo subtype with package-protected constructors to ensure that only the relevant program type constructs SourceInfo objects. Also, as we expand the type of data that's collected, I expect to add additional, per-AST, information to the subtypes. That sounds nice! --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] a code review - issues2905_2909_r3674.patch
John, I'd like you to have a look at the following changes to Safari's history implementation. They're meant to work around the bizarre issues caused by setting Safari's location.hash to an empty string. Please pay particular attention to the ugly URL rewriting code I added to HistoryImplSafari. Patch by: jgw Review by: jat Issues: 2905, 2909 Affected files: M user/test/com/google/gwt/user/client/ui/HistoryTest.java M user/src/com/google/gwt/user/client/impl/HistoryImplSafari.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- issues2905_2909_r3674.patch Description: Binary data
[gwt-contrib] Re: a code review - issues2905_2909_r3674.patch
On Wed, Sep 24, 2008 at 1:51 PM, Joel Webber [EMAIL PROTECTED] wrote: I'd like you to have a look at the following changes to Safari's history implementation. They're meant to work around the bizarre issues caused by setting Safari's location.hash to an empty string. Please pay particular attention to the ugly URL rewriting code I added to HistoryImplSafari. I didn't bring my Macbook home with me so I can't test it -- I assume you have on both Safari 2 and 3. I assume no similar change was needed for Safari 2 since it already does something similar, right? You should update the comment in detectOldSafari since it is no longer accurate. Otherwise, LGTM. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: 1.6 Event handler proposal
Does this proposal mean that if I want to receive the equivilant of
todays Event.MOUSEEVENTS, that I have to call:
widget.addMouseDownHandler( new MouseDownHandler() { ... } );
widget.addMouseUpHandler( new MouseUpHandler() { ... } );
widget.addMouseMoveHandler( new MouseMoveHandler() { ... } );
widget.addMouseOverHandler( new MouseOverHandler() { ... } );
widget.addMouseOutHandler( new MouseOutHandler() { ... } );
If that's the case, then it seems that users of this new API will have
a larger burden... Perhaps there should be a general MouseHandler
that could be used like:
public class MouseHandler implements FiresMouseDownEvents,
FiresMouseUpEvents, ... { }
widget.addMouseHandler( new MouseHandler() { ... } );
This MouseHandler would, internally, add the 6 different types of
mouse event handlers.
I'd expect a similar sort of construct for keyboard events, etc...
If, by some chance, I'm totally off on my understanding, or if what
I'm saying is just completely obvious to everyone else, then please
accept my apologies ahead of time...
And, thanks to all of you working so hard to make the lives of folks
like me so much better! (I would never attempt to write the kind of
application I'm working on in pure JavaScript. That'd suck!)
jay
This comment really isn't a big deal. It would just suck (in my
opinion) to have a whole bunch of people writing the same little
classes all the time...
On Sep 22, 1:02 pm, Emily Crutcher [EMAIL PROTECTED] wrote:
A more complete implementation of the event handlers has been added to
the gwt-incubator
gen2.event
packagehttp://code.google.com/p/google-web-toolkit-incubator/source/browse/#
The next step is to declare the design final, take the code from prototype
to production and submit it to GWT trunk for inclusion in GWT 1.6, so this
may be the last time any of you get a chance to holler if you don't like the
system. The up-to-date design doc is
here.http://code.google.com/p/google-web-toolkit-incubator/wiki/ProposedEv...
For those of you who have been following the discussion already, the main
changes are summarized below. Note, the design doc contains the actual
design, this list is only for the convenience of those who have been closely
following this thread:
1. Added a default Widget.onBrowserEvent
2. subscribeTo mechanism replaced by addAndSinkHandler mechanism
3. For each event type(ClickEvent used as an example)
- ClickEvent.Source -- HasClickEvents
- ClickEvent.fireEvent(Handler) -- ClickEvent.KEY.fire(Event,Handler)
--
There are only 10 types of people in the world: Those who understand
binary, and those who don't
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: GWT 1.5 Now Available
Where can I find normal GWT version for linux now? The link is broken. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r3679 - in changes/jat/oophm-branch/plugins: common xpcom
Author: [EMAIL PROTECTED]
Date: Wed Sep 24 12:42:55 2008
New Revision: 3679
Modified:
changes/jat/oophm-branch/plugins/common/ByteOrder.h
changes/jat/oophm-branch/plugins/common/HostChannel.h
changes/jat/oophm-branch/plugins/common/Socket.cpp
changes/jat/oophm-branch/plugins/common/Socket.h
changes/jat/oophm-branch/plugins/xpcom/FFSessionHandler.h
changes/jat/oophm-branch/plugins/xpcom/JavaObject.cpp
Log:
Checkpoint XPCOM back working except for toString.
Modified: changes/jat/oophm-branch/plugins/common/ByteOrder.h
==
--- changes/jat/oophm-branch/plugins/common/ByteOrder.h (original)
+++ changes/jat/oophm-branch/plugins/common/ByteOrder.h Wed Sep 24 12:42:55
2008
@@ -17,6 +17,7 @@
*/
#include Platform.h
+#include cstring
class ByteOrder {
private:
Modified: changes/jat/oophm-branch/plugins/common/HostChannel.h
==
--- changes/jat/oophm-branch/plugins/common/HostChannel.h (original)
+++ changes/jat/oophm-branch/plugins/common/HostChannel.h Wed Sep 24
12:42:55 2008
@@ -46,7 +46,7 @@
bool connectToHost(const char* host, unsigned port);
bool disconnectFromHost();
-
+
bool isConnected() const {
return sock.isConnected();
}
@@ -90,6 +90,9 @@
bool sendDouble(const double data);
bool readByte(char data) {
+if (!isConnected()) {
+ return false;
+}
int c = sock.readByte();
if (c 0) {
return false;
@@ -99,6 +102,9 @@
}
bool sendByte(const char data) {
+if (!isConnected()) {
+ return false;
+}
return sock.writeByte(data);
}
Modified: changes/jat/oophm-branch/plugins/common/Socket.cpp
==
--- changes/jat/oophm-branch/plugins/common/Socket.cpp (original)
+++ changes/jat/oophm-branch/plugins/common/Socket.cpp Wed Sep 24 12:42:55
2008
@@ -95,14 +95,20 @@
connected = true;
readBufPtr = readValid = readBuf;
writeBufPtr = writeBuf;
+#ifdef _WINDOWS
+ Debug::log(Debug::Spam)connected Debug::flush;
+#else
Debug::log(Debug::Spam)connected, fd= fd Debug::flush;
+#endif
return true;
}
-bool Socket::disconnect() {
+bool Socket::disconnect(bool doFlush) {
if (connected) {
Debug::log(Debug::Debugging) Disconnecting socket Debug::flush;
-flush();
+if (doFlush) {
+ flush();
+}
connected = false;
#ifdef _WINDOWS
closesocket(sock);
@@ -125,6 +131,11 @@
for (char* ptr = writeBuf; len 0; ) {
ssize_t n = send(sock, ptr, len, 0);
if (n = 0) {
+ if (errno == EPIPE) {
+Debug::log(Debug::Warning) Other end of socket disconnected
Debug::flush;
+disconnect(false);
+return false;
+ }
Debug::log(Debug::Error) Error errno writing len
bytes to socket
Debug::flush;
return false;
@@ -138,10 +149,17 @@
bool Socket::fillReadBuf() {
readBufPtr = readBuf;
+ errno = 0;
ssize_t n = recv(sock, readBuf, BUF_SIZE, 0);
if (n = 0) {
- Debug::log(Debug::Error) Error errno reading
BUF_SIZE bytes from socket
- Debug::flush;
+// EOF results in no error
+if (!errno || errno == EPIPE) {
+ Debug::log(Debug::Warning) Other end of socket disconnected
Debug::flush;
+ disconnect(false);
+ return false;
+}
+Debug::log(Debug::Error) Error errno reading
BUF_SIZE bytes from socket
+ Debug::flush;
return false;
}
++numReads;
Modified: changes/jat/oophm-branch/plugins/common/Socket.h
==
--- changes/jat/oophm-branch/plugins/common/Socket.h(original)
+++ changes/jat/oophm-branch/plugins/common/Socket.hWed Sep 24 12:42:55
2008
@@ -118,9 +118,10 @@
/**
* Disconnect this socket.
*
+ * @param doFlush true (the default value) if the socket should be
flushed.
* @return true if disconnect succeeds
*/
- bool disconnect();
+ bool disconnect(bool doFlush = true);
/**
* Read a single byte from the socket.
Modified: changes/jat/oophm-branch/plugins/xpcom/FFSessionHandler.h
==
--- changes/jat/oophm-branch/plugins/xpcom/FFSessionHandler.h (original)
+++ changes/jat/oophm-branch/plugins/xpcom/FFSessionHandler.h Wed Sep 24
12:42:55 2008
@@ -25,6 +25,7 @@
#include jsapi.h
class HostChannel;
+class Value;
class FFSessionHandler :
public SessionData,
Modified: changes/jat/oophm-branch/plugins/xpcom/JavaObject.cpp
==
--- changes/jat/oophm-branch/plugins/xpcom/JavaObject.cpp (original)
+++ changes/jat/oophm-branch/plugins/xpcom/JavaObject.cpp
[gwt-contrib] Re: Safari Empty History Tokens
Thanks, Wayne. I posted a patch earlier today that seems to fix the problem. If you're in a position to try it out, that would be greatly appreciated. joel. On Tue, Sep 23, 2008 at 7:09 PM, WRL [EMAIL PROTECTED] wrote: I just updated 2909 with an example. Thanks, Wayne --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
