Interesting question. It's not immediately obvious to me whether we ought to
be shunting all js-java calls through $entry(). This should really only be
necessary when a call into java is coming from js that is at the top of the
stack. This usually means only event handlers, though if it were
On Mon, Oct 19, 2009 at 11:19 AM, Joel Webber j...@google.com wrote:
Interesting question. It's not immediately obvious to me whether we ought to
be shunting all js-java calls through $entry().
I would say yes, that GWT Exporter should be updated to support
$entry, if for no other reason than
http://gwt-code-reviews.appspot.com/77810/diff/1007/30
File user/src/com/google/gwt/core/client/impl/Impl.java (right):
http://gwt-code-reviews.appspot.com/77810/diff/1007/30#newcode166
Line 166: // What is the correct return value here or should we
re-throw?
Additionally, this could be a
Bob, Hmm, I just caught this thread. It looks like I should be updating
GWT-Exporter library to use this? GWT exporter can export non-static methods
as well, I'm wondering how that meshes with expectations?
-Ray
On Mon, Oct 12, 2009 at 8:39 AM, b...@google.com wrote:
Reviewers: jgw,
Still LGTM, modulo the clarification on return values from event
handlers.
http://gwt-code-reviews.appspot.com/77810/diff/1007/30
File user/src/com/google/gwt/core/client/impl/Impl.java (right):
http://gwt-code-reviews.appspot.com/77810/diff/1007/30#newcode166
Line 166: // What is the correct
http://gwt-code-reviews.appspot.com/77810/diff/34/1016
File user/src/com/google/gwt/core/client/impl/Impl.java (right):
http://gwt-code-reviews.appspot.com/77810/diff/34/1016#newcode54
Line 54: public static native JavaScriptObject entry(JavaScriptObject
jsFunction) /*-{
I think this should be
http://gwt-code-reviews.appspot.com/77810/diff/34/1016
File user/src/com/google/gwt/core/client/impl/Impl.java (right):
http://gwt-code-reviews.appspot.com/77810/diff/34/1016#newcode148
Line 148: _ = jsFunction.apply(thisObj, arguments);
On 2009/10/13 19:13:43, scottb wrote:
What's the
LGTM.
http://gwt-code-reviews.appspot.com/77810/diff/34/1016
File user/src/com/google/gwt/core/client/impl/Impl.java (right):
http://gwt-code-reviews.appspot.com/77810/diff/34/1016#newcode163
Line 163: if (hasEntered) {
On 2009/10/13 19:26:24, bobv wrote:
When we did the emulated JS stack
http://gwt-code-reviews.appspot.com/77810/diff/34/1016
File user/src/com/google/gwt/core/client/impl/Impl.java (right):
http://gwt-code-reviews.appspot.com/77810/diff/34/1016#newcode148
Line 148: _ = jsFunction.apply(thisObj, arguments);
Nasty. Yeah, cromwellian, or maybe spoon.
That's fine for JS stack, but it's not fine for Uncaught EH. You
really have to
fire the Uncaught EH *even in the reentrancy case* because if you're
inside a
new event loop, the exception *won't* propagate to the outer stack,
the browser
will swallow / report it.
Now I understand what
LGTM
http://gwt-code-reviews.appspot.com/77810/diff/41/1023
File user/src/com/google/gwt/core/client/impl/Impl.java (right):
http://gwt-code-reviews.appspot.com/77810/diff/41/1023#newcode163
Line 163: boolean outermost;
Nitpick: this is somewhat confusing. What about a static int
entryDepth?
Reviewers: jgw,
Message:
I'm looking for an initial vetting of the overall idea, not necessarily
this implementation. Obviously, there are additional entry-points that
need to be reworked and $entry need to detect reentrancy.
Description:
This is an attempt to rationalize how external JS code
LGTM
http://gwt-code-reviews.appspot.com/77810
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Hi Scott and Bruce,
@Bruce, can I get feedback on the API that $entry() provides.
@Scott, this changset just has the changes to the compiler and hosted
mode, can you review them?
http://gwt-code-reviews.appspot.com/77810
--~--~-~--~~~---~--~~
On Mon, Oct 12, 2009 at 3:41 PM, b...@google.com wrote:
Hi Scott and Bruce,
@Bruce, can I get feedback on the API that $entry() provides.
@Scott, this changset just has the changes to the compiler and hosted
mode, can you review them?
http://gwt-code-reviews.appspot.com/77810
Is $entry
Is $entry sufficiently obscure to avoid collisions? I would prefer
something like __gwt_entry instead.
It lives in the same namespace as $wnd.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://gwt-code-reviews.appspot.com/77810/diff/1007/30
File user/src/com/google/gwt/core/client/impl/Impl.java (right):
http://gwt-code-reviews.appspot.com/77810/diff/1007/30#newcode166
Line 166: // What is the correct return value here or should we
re-throw?
Shouldn't this be a void method
LGTM
On 10/12/09, b...@google.com b...@google.com wrote:
Hi Scott and Bruce,
@Bruce, can I get feedback on the API that $entry() provides.
@Scott, this changset just has the changes to the compiler and hosted
mode, can you review them?
http://gwt-code-reviews.appspot.com/77810
Shouldn't this be a void method anyway? (and so on up the stack)
If it's non-void, it can be used with something like an onsubmit
handler where the return value alters the behavior of the browser.
Otherwise you'll need some indirect way of communicating the desired
return value to the callback
We need to check this to be sure, but I believe onsubmit, like all the other
DOM events, just uses the return value as another way of calling
preventDefault(). So it's not strictly necessary, unless I'm missing
something.
On Mon, Oct 12, 2009 at 4:54 PM, BobV b...@google.com wrote:
Shouldn't
20 matches
Mail list logo
