could you please post some code as example?

On Fri, Jan 1, 2010 at 5:59 PM, Thomas Broyer <[email protected]> wrote:

>
> 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]<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.


Reply via email to