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.


Reply via email to