Tuesday, June 28, 2011

RequestFactory object lifecycle & change propagation

Hi people,

Since I'm new to GWT in general and RequestFactory in particular I
resort to your experience, cause I'm trying to find out what's the
best way to solve a problem, that has an impact on my application as a
whole, regarding RequestFactory, and I couldn't find a previous
discussion about it.

I have a master/detail, typical CRUD manager where I edit contacts.
Since those contacts rarely surpass 200 or so I thought it was okay to
load them at start time, just like GMail does.

So, I keep them in a singleton ModelLocator, and to render my contact
CRUD and use contacts everywhere in my application I use that
reference. Like, for instance, from a CellTable.

Now, when I'm editing one of those contacts, I invoke request.edit()
so that the changes are tracked in the context of the current request,
and finally .fire(). The remote service method gets called and
everything works fine.

The moment after doing so, I notice that I must refresh somehow
ModelLocator.contacts because it points to an element that now is
stale, it didn't get noticed about the edition.

In an ideal world, I'd like to think of the original RequestFactory
pretty much like a Hibernate session and merge the successful save()
request into the original getContacts() request, so that the original
proxies get updated and finally have just one copy of the data. But as
far as I've seen RequestContexts objects have a rather short
lifecycle.

So, I think most people using RF should have faced the same situation,
what is the best possible solution to this?


Thanks a lot, and I'd greatly appreciate your help

J.

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

No comments:

Post a Comment