OK. Not exactly my finest hour but I have worked around this by creating my
own version of AbstractRequestContext.java that has one additional method:
public void detach(EntityProxy proxy) {
AutoBean autoBean = state.editedProxies.remove(proxy.stableId());
autoBean.setTag(REQUEST_CONTEXT_STATE, null);
}
and at the point where I remove a previously create()ed proxy that I dont
want sent to the server:
((AbstractRequestContext)
requestContext).detach(listEditor.getList().remove(index));
Cheers
Craig
On Tuesday, March 6, 2012 12:35:51 PM UTC+8, Craig Day wrote:
>
>
> Yeah, things break down pretty badly due to this behaviour. Child proxies
> added and then removed via ListEditor are still sent to the server on
> fire(), and subsequent validation of these empty proxies fails the entire
> request. Really only referenced proxies should be sent, or perhaps a
> detach/uncreate/delete method on RequestContext that undoes the create()
> call.
>
> Has there been an issue created for this?
>
> Has anyone come up with a workaround for the problem?
>
> Cheers
> Craig
>
> On Saturday, February 11, 2012 11:32:18 PM UTC+8, Thomas Broyer wrote:
>>
>> Your problem has nothing to do with editors actually, only with
>> RequestFactory. It's true that any edited proxy will be part of the
>> request, whether it's passed (or referenced by another proxy, transitively,
>> that is passed) as argument to a service method or not; and it's also true
>> that as soon as you edit() a proxy, all the proxies it references are
>> automatically edit()ed as well.
>>
>> Given that there's an explicit unit-test testing that such a proxy is
>> actually sent to the server, I guess it's by-design. I suppose one use-case
>> was to edit proxies, make changes to them, and send them for validation
>> without even calling a service method. I fail to see the real usage though,
>> as the objects would be frozen after the call.
>>
>> I however agree I'd rather only "referenced" proxies are sent to the
>> server, and if you want to validate your proxies then create a dummy no-op
>> service method (again, I'd fail to see the real usage, but the point is to
>> say it'd be easy to have the same behavior with only small changes).
>>
>> Another use-case could be to send proxies (without changes) to the server
>> so that you can have EntityProxyChange events back, and thus detect deleted
>> or updated objects; but then again I fail to see a real use-case, as
>> detecting updated objects without retrieving them at the same time is kind
>> of useless in 90% of cases, and again, you can easily have that behavior by
>> only adding a service method call (if you want the changes back, then make
>> an "echo" method that returns its argument, it'd be enough).
>>
>> Feel free to file an issue and link to this message, and let's see how
>> its getting triaged.
>>
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/vS0vB2JysdQJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
