On 01/01/2010 08:59 AM, Thomas Broyer wrote: > > On Jan 1, 1:16 am, Daniel Simons <daniel.simo...@gmail.com> 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.
Thanks for the detailed post, Thomas. -- 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.
