On 22 juil, 04:07, "Jason A. Beranek" <jason.bera...@gmail.com> wrote:
> 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).
Yeah, right, Ray talks about "place change events" and components that
could listen to those to be informed when they're "in use" or not and
unregister/re-register their other handlers on the event bus (it's
around 46:20 in the video).
He doesn't talk about how to communicate with the place service to
update the history token though. I'd say that either components have a
dependency on the place service and call its methods directly (and the
place service updates the history and fires a place change event to
notify other components), or they themselves fire place change events
and the place service listens to them.
But those "place change events" are not that different from the events
I described earlier ("picked contact (the one with ID=12345)")
> 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,
Actually, in Gmail, it can also be "label/My+Label/message-id", but
it's still simply splittable on slashes to extract sub-parts.
> 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.
The Google Documentation Reader <http://code.google.com/docreader>
used to use XPointer-like tokens such as "p(project1,project2)s
(project1)t(topic)" and now uses query-string-like tokens such as
"p=project1,project2&s=project1&t=topic". They're IMO as easy to parse
as "path-like" tokens like Gmail uses; it's just a matter of taste
(and how you'd like to model your internal API)
--~--~---------~--~----~------------~-------~--~----~
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-Toolkit@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
-~----------~----~----~----~------~----~------~--~---
