Wednesday, June 29, 2011

Re: RequestFactory object lifecycle & change propagation

since you want to update your in-memory list you can look at custom events and pass the updated object by throwing an event whenever your contact was modified. Your contact list can listen for this custom event and update the existing object with new data.

with regards to EntityProxyId, you have to main a map of your proxies and their proxyId's. this way you whenever a proxy has changed, you can pick the corresponding proxy from the map and update it by fetching new data from the server.

Thanks
Ashwin

On Wed, Jun 29, 2011 at 7:45 PM, isern <juanisern@gmail.com> wrote:
Ashwin,

Thanks for your reply.

Basically, as I hold an "in memory" contact list (held in
ModelLocator) I'd like to refresh that list with the newly updated
object.

I don't think it's necessary a trip to the server because I know I
have the latest object version (I just saved it!). EntityProxyChange
doesn't seem to provide a reference to the proxy object that triggered
the change.

I'm kind of confused with RequestFactory, I see having multiple change
contexts and multiple proxy graphs as a handicap rather that an
advantage.

:-(


On Jun 29, 12:59 am, "ashwin.desi...@gmail.com"
<ashwin.desi...@gmail.com> wrote:
> J,
>
> did you look at EntityProxyChange.registerForProxyType ? You can use this
> and register for any changes to your entities with the eventBus. The Handler
> method is called on change of entities (especially version changes).
>
> example:
>
> EntityProxyChange.registerForProxyType(eventBus, UserContactsProxy.class,
> new EntityProxyChange.Handler<UserContactsProxy>() {
>
> @Override
> public void onProxyChange(
> EntityProxyChange<UserContactsProxy> arg0) {
>
>                                                           proxyId =
> arg0.getProxyId()
>  //data has changed, so fetch the contact again
> fetchUserContact(prxoyId);
>
> }
> });
>
> Regards
> Ashwin
>
> On Wed, Jun 29, 2011 at 2:29 AM, isern <juanis...@gmail.com> wrote:
> > 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.

--
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.


--
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