On 08/10/2011 01:56, Alan Leung wrote:
I don't really understand this point. Smaller fragments are still
strongly cachable - there are just more download requests, no? In
a multi-page app it is likely that most of the code in the left
overs fragment (used in other pages) will
On 05/10/2011 23:53, Ray Cromwell wrote:
You could try making a split point which contains other split points,
something like this:
I = Initial Fragment
W - Split point from which all Widget using splitpoints exist
W1 - Widget using split point 1
W2 - Widget using split
On Thursday, 6 October 2011 01:02:10 UTC+7, John A. Tamplin wrote:
The basic code splitting algorithm can handle this,
Can you give some more details? I have not seen a solution to this problem
yet.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On 06/10/2011 07:27, Alan Leung wrote:
I have studied Lex Spoon's writeup extensively a few weeks back. While
I do believe it is beneficial to leftover code size,
when I bought it up with some of the internal projects, they believe
the cache-ability lost with multiple leftover fragments is not
Hi,
I'm finding it too difficult to keep code out of the left overs fragment. I
have a single application which has a split point for every html page. Some
of my pages use Widgets and other don't but the left overs fragment contains
all the code to support Widgets which is a huge drag.
On 05/10/2011 23:35, Jens wrote:
I think currently the left over fragment will grow forever if you
introduce new commonly used classes (used in more than one split point).
Maybe a potential solution will make it into one of the next GWT
releases. Take a look
at:
On 26/09/2011 14:11, Ray Cromwell wrote:
Alan Leung of the GWT team is working on a partial fix for this,
called Automatic Fragment Merging, it merges together fragments
automatically in order to reduce the size of leftovers while
increasing the size of the exclusive fragments (which in many
I am also hitting this problem with the left overs fragment and Lex
suggestion does not seem to help.
I have split points A and B which both use GWT-RPC and so all the RPC code
gets moved into the left overs fragment which adds 30Kb to its size. I've
created a new split point C, in front of A
On 31 Mar 2010, at 18:59, Joel Webber wrote:
John,
Sorry for the slow response -- I've had a browser window open for
several days to respond, but I keep getting pulled off onto other
things.
Ha ha! I know exactly how it is.
It sounds like this is indeed an ordering bug. It's hard to
2009/8/4 Rob Heittman rob.heitt...@solertium.com
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.
Boiler plate, _almost_ duplicate interfaces anyone? Business methods
defined in the remote
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
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
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
13 matches
Mail list logo
