I can see that allowing the above would still not solve the async,
single threaded nature of ajax calls.
But there must be some way to reuse the Service interface on the
client.
Perhaps compiling a call to a Service interface could be implemented
in JavaScript like this:
Java:
StockPrice[]
Sam,
I've been wanting to do this since we first introduced the dom package in
1.5. The plan is to remove all extant references to user.Element and
friends, as well as the DOM.* static methods, at which point they can be
deprecated. I'd like to do this as part of 2.0, so that we can go ahead and
What you're describing is formal support for continuations in the compiler.
While I'm sure this is theoretically tractable, there are several practical
issues that are likely to be problematic.
The first is simply that it makes an asynchronous look synchronous, which is
nice on the surface, but
Comment by j...@google.com:
@goo...: Uhh... I'm not precisely sure how you're trying this example,
since I haven't committed or posted the code yet :) I'll have something up
on gwtc this week, which you're welcome to try then.
For more information:
Joel,
I'll give your email to my project manager if you ever touch it again ;-)
David
On Mon, Aug 3, 2009 at 2:26 PM, Joel Webberj...@google.com wrote:
Sorry about that, David. I can promise with reasonable impunity that we
never, ever want to go through the process of changing the event
Thanks for your response Joel
On 3 Aug 2009, at 20:01, Joel Webber wrote:
What you're describing is formal support for continuations in the
compiler. While I'm sure this is theoretically tractable, there are
several practical issues that are likely to be problematic.
Well yes I guess I
The Async interface is necessary because one does not want to use sync
(blocking) rpc calls back to the server. When using blocking calls the
entire browser freezes which is especially bad give responses arenot
instantwous.
Hth
On 03/08/2009, at 1:10 AM, jd jdpatter...@gmail.com wrote:
On Mon, Aug 3, 2009 at 8:30 AM, Joel Webber j...@google.com wrote:
I've been wanting to do this since we first introduced the dom package in
1.5. The plan is to remove all extant references to user.Element and
friends, as well as the DOM.* static methods, at which point they can be
I'd be a lot more comfortable if our own code didn't have reams of
deprecation warnings. The good news is that it's actually pretty easy to do
-- it's damned near rote, though not quite enough to automate. I did it for
a few large classes in 1.5 (though I didn't commit the changes), just to
make
Although it feels less convenient, the async nature of RPC is actually
valuable for usability. It forces you to think about what to do in the
application UI while a potentially long-running activity is taking place.
When you consider that a network round-trip combined with time spent on the
server
Here are the inline code comments.
http://gwt-code-reviews.appspot.com/51804/diff/1/8
File
dev/core/src/com/google/gwt/core/ext/linker/impl/StandardCompilationAnalysis.java
(right):
http://gwt-code-reviews.appspot.com/51804/diff/1/8#newcode57
Line 57: */
Would it make sense to refer to these
I wonder how much work we could make Eclipse do for us. Under the 'Refactor'
menu there are a few useful optional to record / playback refactorings:
Migrate JAR File Migrates a JAR File on the build path of a project in your
workspace to a newer version, possibly using refactoring information
With the advantage of having read GWTCanvas, excanvas.js, and this
discussion, I got an interesting insight about how I actually ended up
using GWTCanvas in Client-side GChart.
It turns out, much to my surprise, that each of the GWCanvas Widgets
used to render my charts could have been realized
I haven't actually tried any of this stuff. I'll definitely have a look when
I hunker down to do this refactoring. Of course, if anyone wants to look
into it before I get to it, that would be even cooler... :)
On Mon, Aug 3, 2009 at 12:13 PM, Fred Sauer fre...@google.com wrote:
I wonder how
Reviewers: bobv,
Description:
LinkedHashMap_CustomFieldSerializer currently uses reflection to access
a private field, which fails in AppEngine. This patch provides a
(possibly slower) alternative approach that does not require reflection,
which is used as a fallback when reflection fails.
Because it's easy to bikeshed: can we make the -soyc (-soycExtra) flag more
like -style in that it has multiple values rather than having two separate
flags? Or is there a rationale for this style that I'm missing.
When Bob V's permutation control changes land, we want to make all of this
sort of
On Mon, Aug 3, 2009 at 2:13 PM, Daniel Rice (דניאל רייס) r...@google.comwrote:
What sort of opt-in mechanisms do you have in mind?
Since this is running on the server, couldn't you clone it and do the add
test there? It might be slow if it is large, but that is better than not
working at
That could still theoretically fail if removeEldestEntry did something
weird that mutated the entries. But that seems pretty unlikely to be the
case.
Dan
On Mon, Aug 3, 2009 at 2:17 PM, John Tamplin j...@google.com wrote:
On Mon, Aug 3, 2009 at 2:13 PM, Daniel Rice (דניאל רייס)
On Mon, Aug 3, 2009 at 2:24 PM, Daniel Rice (דניאל רייס)r...@google.com wrote:
That could still theoretically fail if removeEldestEntry did something
weird that mutated the entries. But that seems pretty unlikely to be the
case.
Which is basically the tension between application code (just
On Mon, Aug 3, 2009 at 1:58 PM, Bruce Johnsonbr...@google.com wrote:
Because it's easy to bikeshed: can we make the -soyc (-soycExtra) flag more
like -style in that it has multiple values rather than having two separate
flags? Or is there a rationale for this style that I'm missing.
When Bob
Reviewers: jlabanca,
Please review this at http://gwt-code-reviews.appspot.com/51830
Affected files:
A layout/Layout.gwt.xml
A layout/client/Layout.java
A layout/client/LayoutImpl.java
A layout/client/LayoutImplIE6.java
A layout/client/UserAgent.java
A
Based on what you said, I like a lot as is. Thanks for explaining it.
On Mon, Aug 3, 2009 at 2:52 PM, Lex Spoon sp...@google.com wrote:
On Mon, Aug 3, 2009 at 1:58 PM, Bruce Johnsonbr...@google.com wrote:
Because it's easy to bikeshed: can we make the -soyc (-soycExtra) flag
more
like
On Mon, Aug 3, 2009 at 12:41 PM, John Gunther
johncurtisgunt...@yahoo.comwrote:
With the advantage of having read GWTCanvas, excanvas.js, and this
discussion, I got an interesting insight about how I actually ended up
using GWTCanvas in Client-side GChart.
It turns out, much to my surprise,
Looks good. A couple of nitpicks, and I want to see it in action, but
no problems so far.
http://gwt-code-reviews.appspot.com/51830/diff/1/2
File layout/Layout.gwt.xml (right):
http://gwt-code-reviews.appspot.com/51830/diff/1/2#newcode17
Line 17: inherits name=com.google.gwt.user.UserAgent/
Two things occur to me:
1) Doing 'instance = instance.clone(); instance.clear()' will guarantee that
neither the current map nor any of its entries can be affected. The only
way something bad could happen would be if clone() or clear() were
overridden to do something weird, but that would
If possible, could someone who is familiar with the ClientBundle /
ImageResource architecture take a look at this issue and let me know if my
diagnosis of the problem seems accurate. If so, does my suggested solution
seem like the appropriate approach?
If so, I'd happily spend the time to create
I've cleaned it up in response to your comments, Kathrin.
I also merged it up to the latest trunk, and I realize that developments
in trunk mean that a new way is needed to record string sizes. That's
next.
http://gwt-code-reviews.appspot.com/51804/diff/1/8
File
On 3 Aug 2009, at 22:22, Bruce Johnson wrote:
Although it feels less convenient, the async nature of RPC is
actually valuable for usability. It forces you to think about what
to do in the application UI while a potentially long-running
activity is taking place.
I can see how the
While this thread may already have gone on too long in the wrong
place, I do just have to say ... I don't use RPC at my shop. It is a
bit forced, as the underlying RESTful plumbing of the web doesn't map
tightly onto the RPC paradigm. GWT puts RPC style coding in reach,
but I still
On 4 Aug 2009, at 09:26, Rob Heittman wrote:
I do just have to say ... I don't use RPC at my shop. It is a
bit forced, as the underlying RESTful plumbing of the web doesn't map
tightly onto the RPC paradigm. GWT puts RPC style coding in reach,
but I still prefer to opt for pure REST. I
I bet you were into the lovely EJB artifacts too? Ha ha this is strangely
reminiscent.
No, I wasn't. Really, I don't see the correlation. But, as you like RPC
abstractions and I don't, I think we can just agree to disagree on religious
principles, and leave it at that. Maybe take it up
31 matches
Mail list logo
