We do #2. We have a custom label class that cuts out after a predefined character count or width. If the text is longer than the defined width we add a clickable '...' at the end of the label When the user clicks that we show the full text in a popup window below the original label. There's usually not that much text in our paragraphs (at most 50-100 chars) though and we're not targeting low bandwidth devices so always sending the full text wasn't really an issue with us.
On Jan 18, 1:31 am, zixzigma <zixzi...@gmail.com> wrote: > Take GMail for example. > in the Inbox, you have a list of received emails, > > in addition to the mail Subject, there is a sentence from the opening > of the email. > in other words we have Subject + MAIL_BODY.substring(0, LENGTH) > > what is the best way to implement this feature ? > > if we were dealing with non-String objects, it made sense to just > fetch the fields that are necessary, > like a summary view, and provide detail as user required. making it two > + step process. > > but in this particular case, we have a list of paragraphs, and want to > provide a one line summary of each. > to prepare this one-line summary, we need to retrieve the entire text, > and then call substring, to get the one line summary. > > I have 3 solutions, but appreciate if you weigh in on how you would > implement this particular usecase. > > Solution #1 > > 1- get the text from the DB > 2- extract the first X characters (one-line summary) [do this on the > server] > 3- send this one-line summary to the client > 4-when client decides to see full text, sends a request > 5-this time send the full text > > Pros: - less data over the wire (instead of pargraphs after > paragraphs, only one line is sent) > Cons: - subsequent client requests would result in additional network > roundtrip > - string manipulation/extraction to produce the one line > summary results in delay > > Solution #2 > > 1-get the text from DB > 2-send the entire text to the client > 3-when displaying, show only the first sentence, > do this by extracting first X characters, doing this on the client > > Cons: transfering so much data can cause delay > Pros: - after initial load, fewer network roundtrip to fetch more data > - text manipulation on the client, > means no delay as a result of waiting for the server to do > the manipulation > > Solution #3 > > having a bit of redundancy, > add an additional field/column to hold the one-line summary. > in other words instead of making one-line summary derivative attribute > (which can be extracted by processing the entire text), we do it once > and store it in the Datastore. > upon user request, we grab this one-line summary column/field. > if user required complete paragraph, we get the column/field > containing the full text. > > Cons: redundancy might result in inconsistency, additional work to > keep data consistent > - when user requests for full paragraph, this results in a > server call, which > is not going to happen with Solution #2 > Pros: - no repeated processing overhead (text extraction/manipulation) > - best use of bandwith, never sending anything thats going to > waste. > > I am thinking of chosing Solution#3, > based on an advice by Google, > that basically stated Storage is cheap, but Bandwith is not, > and user attention span is short therefore no delay ! : ) > > have you implemented this functionality ? > whats your thought on this, > what would you do ? -- 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-toolkit@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.
