Well of course there's no need to send the state to the server, just capture it and maintain it on the client (of course the user can't copy the link to send to someone else, just use it locally). Just mentioning that if you already do send the data to the server for other reasons, you already have the capture state methods done. As for reconstructing, I don't know your app but would be surprised that it would be too difficult - I've done this lots on various complexity of widgets, and while a little tricky in some cases, once done it makes the programming model much easier.
On May 20, 9:21 am, Mike Jiang <mikej1...@gmail.com> wrote: > Understand what you suggested. Thanks. > > The reason for doing this way is based on the following considerations, > > 1. The screens are saved as objects completely on the client side. No > client-server networking traffic issues during the storing and reloading > process. Even in multiple concurrent client environment, it would not cause > problem on server side. the only expense is on the individual client ; > 2. Extracting the data and saving the data only would be a good idea, just > like sending bare data rather than sending a serialized object as a whole > with overhead across the network. The problem is that reconstructing the > screen is not a simple job, especially for a rich component screen. Thus I > would like to borrow the idea of the object serialization scenario. > -- 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.
