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.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
