Without this it is basically impossible to generalize a mechanism for keeping a bit of UI up to date in response to RecordChangeEvents.
An Editor wants to be notified when the value that it is editing has changed (it might be a read-only or in-place editor). So that the Editor widget doesn't have to be tightly coupled to the RequestFactory, it calls EditorDelegate.subscribe(myValue).
This will cause the EditorDelegate to subscribe to the right kind of record change event on the RequestFactory's event bus. Since the event received by the EditorDelegate no longer includes any useful data, how does the delegate get updated data to send back into the Editor?
In order to provide this server, the EditorDelegate will need to issue its own findFoo() request when the update is seen. The event includes all the info it needs to make that request.
How do I know what to call?
There's no requirement that find() is available to the client. How do I use the TypeOracle to actually locate the right thing to call? Look at all service locator methods on the RF interface and then see if any one of them contains a method named findX that accepts a single long and returns the desired type?
Clearly not a livable situation. Now, given that our service object helper class will require the implementation of a find(id, type) method, it seems reasonable to expose the same kind of method client side on RequestFactory itself. This may even hint at the shape our caching should take.