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. On Thu, May 20, 2010 at 10:24 AM, kozura <[email protected]> wrote: > In general, trying to store the application state by storing the > widget itself is a bad idea, would be very expensive and of course > with no deep clone doesn't even work. Better is to extract just thein > data needed to reconstruct the widget state and store that, then > reconstruct the state on history changes. Depending on your app > design you may already have methods to do this, ie to build the > initial widget contents or to send them back to the server. > > Also as an aside, note that History.newItem() will actually call the > history change event, which in this case would immediately try to > reconstruct the widget with the data you just captured (or are about > to capture). Be sure to add a flag or something so your change > handler does not do this unnecessary restore when you are manually > adding history items. > > On May 20, 7:33 am, Mike Jiang <[email protected]> wrote: > > I tried to use History class to manage the handling of the back/forward > > functioning of the browsers. In order to do that, I need to save the > screens > > with state to a collection, such as a HashMap, hmap. > > For example, the screen is represented by a Composite object, compObject, > > which contains a widget object: wgtObject. Every time when I said that > the > > screen was changed, it implied that the only the wgtObject was changed. > When > > I used the History to do that, the code is like, > > > > Hostory.newItem(screenName); > > hmap.put(screenName, compObject); > > > > However, since the compObject is the same instance, on the > onValueChange() > > > > public void onValueChange(ValueChangeEvent<String> event) { > > String screenName = event.getValue(); > > Composite composite = hmap.get(screenName); > > if (compObject != null) { > > RootPanel slot = RootPanel.get("mainPanel"); > > slot.clear(); > > > > slot.add(composite); > > > > } > > } > > > > even the code turned to different screens, the same screen remained > > unchanged. The reason is that the compObject rather than wgtObject is > saved > > to hmap! > > > > But I need to save compObject with its state to hmap. So I need to clone > the > > compObject before saving it to hmap. Since there is no Object.clone() > > available for GWT, how can I do that? > > > > Thanks, > > > > Mike J. > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-web-toolkit%[email protected]> > . > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
