On 16 juin, 21:42, Kevin Q <[email protected]> wrote:
>
> However, one part Ray didn't elaborate too much but I think is very
> important is the PlaceService (a higher level abstraction layer on top
> of the History mechanism). The ability to throw PlaceChanged events on
> the EventBus and let the interested parties to deal with the place
> change is a very flexible and elegant system. That being said,
> however, I'm a bit unsure about the implementation and Ray was also
> kind of shy on detail of it during the talk. I'm wondering if anyone
> has done something similar and can share a pointer or two.
I'm unsure Ray talked about "PlaceChanged events"; my understanding is
that the PlaceService:
- listens to History ValueChangeEvent's and map them to "business-
level" events (from #contact/<contactId> to ShowContact(<contactID>)
for instance)
- listens to business-level events and map them to History changes
(History.newItem(<token>, false))
...and Ray actually talks about different "place objects", each
responsible for a part of the "history-token <-> event" process.
I've been thinking about this kind of event bus approach since day 1
of our project (a bit more than a year ago) but we didn't have time to
put it in place. This "place" service is probably something I would
have come to too; at least the addition of the History::newItem
(String,boolean) overload was something that rung in my head as making
such a thing (call newItem once the "screen" is showing, not as an
"event" in order to show it; which is what we're doing now) easier.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
