I've been looking at the place service as well, but while I don't agree with exactly the structure in David Peterson's example, I'm not sure if the place service should fire an IssueEditEvent that drives some UI change. From the Ray Ryan presentation, my impression is the Place Service functions as an abstraction between client code/widgets and the History API allowing client code to decouple from the specifics of parsing and generating history tokens. The Place Service in that model is the sole handler of History events, and possibly one of the limited set of interfaces that programmatically set History (though you could use HyperLink widgets as the only means to control the token, however this complicates the creation of tokens).
As for the structure of the Place object, one approach is to use a simple key/value pair for the location, for example: #key #key/value This seems to be the same approach used in the current Gmail, and seems like a good approach for some navigation schemes. Personally, I'd avoid more complex representation of Places, as it complicates parsing and Place change processing. However, your mileage may vary. -Jason On Jul 21, 6:55 pm, Eduardo Nunes <[email protected]> wrote: > On Tue, Jul 21, 2009 at 7:07 PM, Thomas Broyer<[email protected]> wrote: > > > On 15 juil, 21:36, David Peterson <[email protected]> wrote: > > >> Presenter Pattern API:http://code.google.com/p/gwt-presenter > > > I wouldn't have made the "place" a part of the presenter (it isn't any > > different than the presenter registering itself a change handler on > > History). > > The whole point of the "place" service is to decouple your "URL > > patterns" from your components: the place service just: > > - listens to history change events, "interprets" them and fire > > appropriate events on the event bus ("please display the contact with > > ID=12345", "please display the list of contacts") > > - listens to events fired by other components and updates the URL > > (History.newItem(newToken, false)); for instance, when you click on a > > contact in the contact list, the list fires a "picked contact (the one > > with ID=12345)" event, some component listens to it and updates the > > display to show the contact info, and the place service listens to it, > > maps it to a history token and updates the History. Or maybe the > > component that displays the contact fires a "contact displayed (the > > one with ID=12345)" event, and the place service listens to this one > > instead. > > Good point Thomas. So, the place service would directly call some > presenter or talk to the presenter by events. > Considering my sample application and the url > (http://host/bit.html#edit;issue=1): > - the place service would fire an IssueEditEvent with the issue id=1 > - the main presenter would take this event and call the appropriated > method in the IssueEditPresenter > > Thanks for the feedback Mr. Broyer, I will make a mix of the > gwt-presenter project and mine, implementing this place service as > well. > > Best regards, > > > > > Maybe this fits into your gwt-dispatch project instead, but that's how > > I would model the "place service". > > -- > Eduardo S. Nuneshttp://e-nunes.com.br --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
