Comment by rj...@google.com:
Hmmm. On the other hand, so far paths seem to be entirely for server side
consumption. Client side you subscribe to the entity field at the last hop
on the path, I hope.
So you declare me.boss.displayName on the client. That goes to the server
and comes back as, effectively, Employee{id: bossId, version: bossVersion}.
The subscriber is tied to bossId+DISPLAY_NAME, not me.boss.displayName.
Later when someone else in the app updates the employee with id=bossId,
I'll hear about it because that's the key to my subscription. I *think*
that could still work with the ognl-on-the-server approach?
The usual complaint about OGNL is that it throws type safety out the
window, but that needn't be true for us, presuming the code generator has
access to server types. If we're willing to fail on polymorphism.
Or, perhaps value store subscriptions *are* keyed by path. But then I think
we'll wind up with redundant values. How can I tell that
findAllEmployees()[25] is the same as Employee{id: bossId}? I'm counting on
being able to use the ValueStore as a cache, and avoid emitting redundant
rpc calls. Can that work in this more webwork-like world we're describing?
For more information:
http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryPlusPaths
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
