always use it to keep the latest version of the proxies. Identity map
updates and propagations could definitely go via the EventBus.
Just wanted to make sure there wasn't a provided way of doing this.
It's unfortunate that this should be done in a manual fashion, I mean,
the RequestContext, AFAIK, has an request-scoped identity map too so
it'd suffice to let a RF be reused over and over.
Thanks for your help!
On Jun 29, 11:47 am, "ashwin.desi...@gmail.com"
<ashwin.desi...@gmail.com> wrote:
> 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 <juanis...@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