RequestFactory: creating proxies on client and constructors

[Ryan McFall]

If I have an Request object and I call create to generate a new proxy
instance, when, if ever, will my constructor for the class that is
being proxied be called? It seems this is the purpose of the create
method in the Locator class, but I don't see that method being
called. I guess I'm not really clear what the purpose of that method
is, if it isn't to construct new instances of proxied objects.

The documentation on creating new objects on the client side indicates
that I should make a call to the server to save it (persist it's
called in the tutorial, which I understand is an arbitrary name). Is
this when the Locator create method is called - the first time a
method referencing the proxy is invoked when the proxy is not
associated with an instance on the client?

Thanks for helping clear up my confusion.
Ryan

[Kevin Anderson]

The purpose of the create method is to associate a request context with the newly created object. It has to be done through the RequestContext so that it can be managed and all the goodies that come with request factory can be enforced.

[Ryan McFall]

Are you referring to the create method on the client (in my
RequestContext sublcass), or the create method in the Locator (which I
believe would be run on the server)?

I think you're referring to the client-side create method; my question
about create is mostly what the server-side version is used for.

The context of the question is this: I have a Boolean property for my
domain object. If I RequestContext.create a proxy and then try to
access the Boolean, I get null. My domain object sets this property
to a default value in its constructor, but the constructor is not
called if all I do on the client is RequestContext.create the proxy.
I was hoping to be able to write default values for properties in a
single place. The domain object on the server seems to be the most
logical place. Currently it seems that I need to save the new proxy
on the server after RequestContext.create'ing the proxy for this to
happen.

Ryan

[David Chandler]

Ryan, you're correct. Nothing on the server gets called until you fire() the request, so your default properties won't be immediately available on the client, unfortunately.

--
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
David Chandler
Developer Programs Engineer, Google Web Toolkit
w: http://code.google.com/
b: http://googlewebtoolkit.blogspot.com/
t: @googledevtools

[Ryan McFall]

Thanks David, for confirming my suspicions.

I've got this working now so that immediately after I
RequestContext.create my proxy, I call a method on the server to
persist it.

In side that server method, I refresh the state of the object after
saving it, because a database trigger populates some tables associated
with the object when it is first created. On the server side, I see
those fields being assigned values in my debugger after the refresh.
I do update the version number field for the object on the server in
my service method.

However, on the client side, the proxy returned by
RequestContext.create does not have those new values; the collection
containing them is still null, as it was before I persisted the
object.

I have some ideas on how to fix this, but I'd love to hear suggestions
on the best way to do it. I feel like the client-side event bus stuff
could be involved here, but honestly I don't know much about how that
works - where is a good place to look for docs (the getting started
with RequestFactory guide doesn't really talk about it).

Ryan

[David Chandler]

Hi Ryan,

The proxy you get from RequestContext.create() won't be updated automatically. Your persist method should return the newly persisted object from the server.

Does that help?

/dmc

[Ryan McFall]

David:

Yep, I thought of that, and have implemented it. It seems to work
well. Thanks for your help!

Ryan