On Jan 1, 1:16 am, Daniel Simons <[email protected]> wrote: > I would be interested to know, for those that have studied the Hupa Project, > and now the Contacts Project, what do you think is the more appropriate way > of handling the Back/Forward browser button actions. Both methods seem to > have there own flaws, for instance, as a project gets larger, the method in > the Contacts Project of AppController handling value changes could quickly > grow to an unmanageable level. On the other hand, the design used in the > Hupa Project where each presenter has an onPlaceRequest(PlaceRequest > request) method, limits the History token creation to the Presenter.bind() > method.
I haven't studied either the Contacts sample or Hupa project, but here's what my PlaceManager is doing: - an HistoryMapper is injected in the ctor and maps history tokens to Place objects, and Place objects to history tokens (I have a bunch of utility classes to compose an HistoryMapper composed of other HistoryMapper instances: using the chain of responsibility pattern, based on prefix matching, etc.) - PlaceManager fires a PlaceChangeEvent whenever a History ValueChangeEvent is fired (i.e. back/forward browser buttons management); it has an explicit navigateTo(Place) method that to set the current Place, fire a PlaceChangeEvent and update the current history token using History.newItem(mapper.stringify(place), false) (see below for details); that way, PlaceManager is the *only* object that ever works with the History class. - presenters *explicitly* register PlaceChangeEvent on the PlaceManager - navigation is "vetoable" (*even* browser-generated navigation, *and* Window.onClosing) to allow for "you haven't saved your changes, do you really want to leave this screen?" scenario; this is done with a vetoable PlaceChangingEvent being dispatched before the PlaceChangeEvent take place (this is why I have an explicit navigateTo method, instead of firing events directly on the EventBus) - Place is just an interface, with no method; you create classes implementing it (such as ContactsListPlace and ContactsDetailsPlace, I even have enums that implement the interface) and generally use "instanceof" in your PlaceChangingHandler and PlaceChangeHandler impls. You can have a ContactsPlace as the base class for ContactsListPlace and ContactsDetailsPlace to setup the "screen" for the "contacts module" (this correspond to a "tab" in our app), whichever exact "screen" from this module is "invoked" (this is very useful for the "main presenter" to highlight/select the appropriate tab, for instance; then the tab widget uses the more "precise" ContactsListPlace and ContactsDetailsPlace to choose which presenter/widget to use) Everything is explicit, and the mapping of history tokens to Place objects is completely disconnected from the presenters (they only deal with Place objects); and using the utility classes, this mapping is modular and easier to maintain (for instance, we have one HistoryMapper per "module" --which can be composed of other mappers already-- and compose them using prefix matching in a global mapper to be passed to the PlaceManager. -- 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.
