... or maybe an improvement, whereby fields marked @Transient would always be sent, and not use the usual lookup/compare workflow?
I'm surprised it works the way it does - when the original value is fetched, we set the @Transient values when returned to the client. But when RF looks up the current value to compare, it will always be null because the regular lookup doesn't set the transient value. So it would be comparing null to the value the client currently has - why wouldn't that cause it to send the value? Or, I guess, the value is compared on the server, and since the client perceives that the value hasn't changed, it's comparing (null == null), I guess that's it, eh? Anyway, some way to force it to send a value would be nice. - Tim On Wednesday, October 26, 2016 at 10:59:43 PM UTC-7, Thomas Broyer wrote: > > Assuming an EntityProxy here, if the field is left unchanged, then it's > not sent to the server. On the server side, the entity is loaded by the > Locator and then the diff is applied. So if the Locator gets a null field, > it'll be left null. > You may have to use a ValueProxy here… -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
