Hi Chris,
I would suggest to go down another path, based on what ive found to be fast
in GWT and whats not:
Your performance issue seems to derive from two problems: first GWT RPC and
second single DOM manipulations.
To get your datastructures faster into the client I would suggest reading up
on GWT Javascript Overlays and JSON. I recently replaced GWT RPC in a large
project with lots of hased structures and we could drop the average
serialization time in the client from 2 secs to 20 ms. (but be aware of the
Javascript overlay restrictions)
The second thing is DOM operations in general are very expensive and widgets
are event more expensive. I would suggest to go the same way like CellTable
did. Render your content as html inside only one widget. THis will handle
all events. I did this by giving each element inside the markup an id,
events bubbled up to the widget where id figured out which element was
clicked, changed or whatever....
You should also take a look at the Cells introduced with celltable and their
Templates...
Hope i could give you some pointers.
-Daniel Kurka
2010/11/2 Jeff Schwartz <jefftschwa...@gmail.com>
> I believe it would be trivial in that you would only need to add OnClick
> event handlers for each of your divs. You would also have to refactor the
> divs to be actual widgets such as Labels. If you are using UiBinder this
> will be a piece of cake though if you aren't it is only slightly more
> complex.
>
> However, with that said, when you render the view which contains the text
> elements that the user can click on then why don't you also call back to
> your server with a list of those elements and using that list, return
> whatever information pertains to each item in the list. If you return a
> HashMap, for instance, then your OnClick handlers would just need to do a
> get("someKey") on the HashMap to retrieve what ever information is tied to
> the element that the user clicked on. If I were designing this that is how I
> would do it. It is a very "ajaxian" way of doing things like this.
>
> If the list of clickable elements is extremely large (in the thousands) or
> if the data tied to those elements is large then you can defer calling back
> to the server until each item is clicked. In this case you would only return
> the data pertaining to the clicked item from the server back to the client.
> Depending on your server's response time (start up latency, for example)
> this may also be a good solution.
>
> Both of the 2 above aren't difficult to achieve. GWT actually makes it
> very easy, in fact (GWT is absolutely fantastic!!!). Just one word of
> caution, mark all you data structures as serializable otherwise you will get
> weird errors when you call back to your server or worse, you will get no
> errors but the data transported back to the client will not be right.
>
> Jeff
>
>
> On Tue, Nov 2, 2010 at 9:45 AM, Chris <christopher.burr...@gmail.com>wrote:
>
>> Thanks Jeff. I had thought of that idea, but then I'd somehow need to
>> tie in to the GWT event model so that I could capture when people
>> click on this text, firing through all my presenters and event bus. (I
>> just realised that I missed that bit off the first message).
>>
>> Perhaps though that is fairly trivial?
>> Chris
>>
>>
>> On Oct 30, 1:42 pm, Jeff Schwartz <jefftschwa...@gmail.com> wrote:
>> > BTW, if the process to generate the content on the server were very
>> > intensive and you wanted to minimize the impact of generating your
>> content
>> > on other users you could break the process up into smaller chunks or
>> work by
>> > making repetitive calls back to the server. How you'd coordinate these
>> calls
>> > with your client would be use-case dependent of course.
>> >
>> > For example, if you are deploying to App Engine you could use tasks &
>> the
>> > datastore to do this:
>> > 1) 1st call back to the server asks to start the process of generating
>> your
>> > content which kicks off a task to do it and when it completes it stores
>> the
>> > generated content as a string in a datastore entity. This could actually
>> use
>> > more than one task but again is use-case dependent.
>> > 2) onSuccess method of the step 1 above loops call backs to the server
>> to
>> > check if the entity in the table exists. If it does the server returns
>> the
>> > string in the payload otherwise it returns null.
>> > 3)onSuccess method of step 2 above checks for a valid string having been
>> > returned and if true appends it to the dom. If null was returned it
>> would
>> > just continue looping until a valid string were returned.
>> >
>> > While this process is ongoing you could put up an activity ajax
>> indicator so
>> > the user knows that there is something 'cooking'.
>> >
>> > This is a very 'ajaxian' way of doing things.
>> >
>> > Jeff
>> >
>> > On Sat, Oct 30, 2010 at 9:28 AM, Jeff Schwartz <jefftschwa...@gmail.com
>> >wrote:
>> >
>> >
>> >
>> >
>> >
>> > > Setting inner text or html for each item will be very, very slow if
>> done on
>> > > the client.
>> >
>> > > I'd generate all the items inside a parent container on the server in
>> a
>> > > string and send that back to the client. Serializing the strong for
>> > > transport will be very quick.
>> >
>> > > On the client when you get the result back from your call to the
>> server you
>> > > would just need to call one inner text or html call using the string
>> > > returned which will be very quick.
>> >
>> > > Jeff
>> >
>> > > On Sat, Oct 30, 2010 at 8:52 AM, Chris <christopher.burr...@gmail.com
>> >wrote:
>> >
>> > >> Hi All
>> >
>> > >> I have this application where I need to display lines of related text
>> > >> one under the other. For e.g., the English text would be on top, and
>> > >> then the Greek would be below. The text is split into phrases, so for
>> > >> example, the Greek is not necessarily in the right word order. All
>> > >> that matters is that the meaning of the greek word matches the
>> meaning
>> > >> of the english word.
>> >
>> > >> How would you go about displaying this. I decided to go for a div
>> > >> containing child divs for each word. Each parent div then floats to
>> > >> the left, so that the wrapping of the text at the end of the page is
>> > >> maintained.
>> >
>> > >> The problem I have is 2 fold. For even small texts (~600 words), it
>> > >> takes a while to generate the correct DOM (600 parent divs at the
>> > >> minimum + for 2 lines 1200 child divs!). Are there ways of speeding
>> > >> this up? At the moment, I take each word-set as it comes in and
>> render
>> > >> the div into the DOM tree. Would it be faster to do everything off
>> the
>> > >> DOM and then attach the whole lot at the end? I believe I tried that
>> > >> months ago and it didn't seem to help much.
>> >
>> > >> Secondly, I get the impression it takes a while to deserialise the
>> > >> response from the server. For e.g. I have a response that is roughly
>> > >> 41Kb from the server, and it seems to take approximately 20 seconds
>> to
>> > >> deserialise.
>> >
>> > >> All this is in DEV mode. In normal mode things are faster, but still
>> > >> not fast enough...
>> > >> Any ideas? I have a few thoughts, but I think that fundamentally this
>> > >> might just not have a nice solution.
>> >
>> > >> --
>> > >> You received this message because you are subscribed to the Google
>> Groups
>> > >> "Google Web Toolkit" group.
>> > >> To post to this group, send email to
>> google-web-tool...@googlegroups.com.
>> > >> To unsubscribe from this group, send email to
>> > >> google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com><google-web-toolkit%2Bunsubs
>> cr...@googlegroups.com>
>> > >> .
>> > >> For more options, visit this group at
>> > >>http://groups.google.com/group/google-web-toolkit?hl=en.
>> >
>> > > --
>> > > Jeff
>> >
>> > --
>> > Jeff
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google Web Toolkit" group.
>> To post to this group, send email to google-web-tool...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/google-web-toolkit?hl=en.
>>
>>
>
>
> --
> Jeff
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To post to this group, send email to google-web-tool...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
