Is there a way to cancel/destroy a RequestContext or EditorDriver while editing?

[tom]

Hi,

in my app, I've got an edit form which uses the Editor framework to edit an EntityProxy.

There's also a delete function, which may be activated while an entity is being edited.

Now the problem is that I can't just open a new RequestContext for an Entity and call remove() on it while it is still being edited (as that would mean "crossing the beams"). So what it does now is first persist() the edited Entity and then remove() it, which causes unnecessary traffic and delay.

How can I tell my EditorDriver to cancel editing? Or alternatively throw away the whole RequestContext in which the editing takes place?

Regards

Tom

[Aidan O'Kelly]

You don't need to decide whether you call persist(), or remove(),
until the user decides to save or delete the entity, so you can use a
RequestContext to start editing, and later, depending on what the user
decides to do, call either persist() or remove() in that same
RequestContext.

Slightly inefficient I suppose, as the changes made to the Entity will
still get sent to the server even when calling remove(). If you don't
want to send the changes when calling remove, simply do not fire() the
context you are editing in (effectively throwing it away), and create
a second context to call remove() on.

> --
> 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/-/85SdohRBg6sJ.
> To post to this group, send email to google-we...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-tool...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>

[Thomas Seven]

2011/9/28 Aidan O'Kelly <aid...@gmail.com>

 

If you don't
want to send the changes when calling remove, simply do not fire() the
context you are editing in (effectively throwing it away), and create
a second context to call remove() on.

Ok, I tried this and it's working. I have to flush() the editorDriver before remove()ing the Entityhowever. Otherwise I get

java.lang.IllegalArgumentException: Attempting to edit an EntityProxy previously edited by another RequestContext

Thanks for helping!

[Thomas Seven]

2011/9/29 Thomas Seven <major...@gmail.com>

Update: It only works if I flush() the EditorDriver and then fire() the resulting context.

[Aidan O'Kelly]

On Thu, Sep 29, 2011 at 9:26 PM, Thomas Seven <major...@gmail.com> wrote:
>
> Update: It only works if I flush() the EditorDriver and then fire() the
> resulting context.
>

Oops, I was mistaken, you cannot have two mutable versions of the same
proxy at once, so you cannot simply not fire() the context to discard
it as I said. !
Seems like there should be a way to discard a context and any
accumulated changes in that case.. I don't see a way to do this in the
docs..

It sounds like your actually persist()'ing the object and then
remove()'ing it in a subsequent request. Not a big deal, but it is
possible to do it in just one request. Its a matter of keeping around
the RequestContext you pass to your editor driver, and deciding which
service method to invoke on it later. Say its called 'editContext' and
you start your editing like:

editor.edit(proxy, editContext);

Later you can either persist:

editor.flush(); // flush() returns the RequestContext passed into
edit(), for convenience, but we are keeping it around anyway.
editContext.persist().using(proxy)
editContext.fire();

Or remove:

// No need to call flush(), we don't care about any changes.
editContext.remove().using(proxy)
editContext.fire();

I think in a few of the docs/examples, the persist() method is queued
at the same time as starting the editing, but it can be delayed until
later, when you know you are actually going to persist it. Again, its
just a matter of keeping around the 'editContext' and deciding which
method to call on it once you know.

PS. Your persist()/remove() calls might look like 'persist(proxy)',
instead of 'persist().using(proxy)'