BTW, the app is still in development and there's lots of good stuff still left to implement but I have a rather large number of members already who I think are mostly interested in (at this time so far) seeing how my implementation is progressing.
Jeff On Thu, Jan 6, 2011 at 12:10 PM, Jeff Schwartz <jefftschwa...@gmail.com>wrote: > I agree with Thomas and would add the behavior your are seeking to > implement is counter intuitive to what people expect when using browser > history. As such then I'd either try to adapt the application so that the > browsers navigation mechanism maintains the user's expectations or forgo > using history altogether which isn't such a far fetched idea considering the > power that GWT provides for creating applications that mimic desktop > applications; you can legitimately consider not using history a viable > solution. I've done just that when I was in the designing phase of my latest > application, http://lovemyvehicle.appspot.com/, and I decided to only use > navigation for the registration process which is sort of a wizard (at least > at this time, it might change as I give it more thought and get more > feedback). Once a user has become a member and logs into the application it > uses no navigation at all. > > The application my members see is highly modeless. State is maintained in > most of the views so that switching to another view and then back using the > applications menu structure brings the user back to the same view and state > they were at before they switched views. Communication between views is via > an EventBus and events are consumed by all concerned views so that when one > view's state is changed it is immediately picked up by any view interested > in the event. This model is very intuitive and I am getting a lot of good > feedback on it. > > So what I am suggesting is that there are alternatives to history if you > are so inclined to imagine them. > > Good luck. > > Jeff > > > > On Thu, Jan 6, 2011 at 11:40 AM, Thomas Broyer <t.bro...@gmail.com> wrote: > >> Well, PlaceHistoryHandler uses an Historian (DefaultHistorian by default, >> which delegates to the History class), so you can easily replace the >> implementation there. >> But really, I wonder how you'll make it work OK with the back/forward >> browser buttons, particularly when going back/forth not a single "place" at >> a time (i.e. open the back/forth menu and go several steps back/forth; >> similar issue with bookmarks). >> >> IMO, what you're trying to do is simply impossible. >> >> -- >> 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 Schwartz* > > -- *Jeff Schwartz* -- 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.
