You can either keep a reference to ctx2 and call persist() after the
flush() of the editor driver; or you can cast the RequestContext returned
by flush() and call persist on it (the returned RequestContext is the one
you passed as an argument to edit(), so it's == ctx2).
Or you can enqueue the
you mean keep a reference to ctx2 and call persist on it after the flush ,
becouse persist requires the proxy, i think i finally got the bit about
queing, and i'm going for the edit-persist sequence, and flush-fire (which
won't make much sense readability wise), but then again, neither is most of
RequestFactoryEditorDriver#flush simply copies the data from the widgets to
the EntityProxy, so either you validate data in your widgets (calling
EditorDelegate#recordError; see the ValueBoxEditor for an example) or you
validate your proxy, but you'd have to flush() first so the proxy is
ok let's assume i'm using the server side validation ,is there any easy to
get the control which has the wrong value (i'm assuming the use of path is
needed) from the editorError?
On Wed, Nov 30, 2011 at 12:38 PM, Thomas Broyer t.bro...@gmail.com wrote:
RequestFactoryEditorDriver#flush simply
Yes, you can control. In your RequestFactory fire operation, override
the OnConstraintViolation method in the receiver, like below.
@Override
public void onConstraintViolation(
the javadoc says that it sends the method invocations and setters to the
server, now what?
the Editor Driver of Rf returns the requestContext, which doesn't give me a
way to get the updated EnitityProxy i can send to the server, so i'm
assuming it does get sent allready, but where can i get
You can listen for EntityProxyChange events on the EventBus. If your entity
has been edited a corresponding event will be fired so you can fetch a
fresh copy from the server.
Alternatively you could define a persist() method in your RequestContext
that does return the persisted Entity. That
In addition to Jens answer: the RequestContext is a queue of invocations
and edited proxies. Only when fire()d the RequestContext will flush that
queue into an HTTP request.
Each invocation can have a Receiver set using Request#to(Receiver), and the
RequestContext can have a global Receiver
but that's the thing i don't get, you refer to the point AFTER i persisted
the entity, but what i'm talking about is how do i GET the new changed
entity proxy so i could send it the persist method. i mean just using the
fire won't magically persist the thing. unlike the find method in the
entity
If you don't define a persist() or whatever method in your RequestContext (and
call it), you won't persist or whatever anything. A fire() would send the
changes to the server but it would then do nothing with them.
--
You received this message because you are subscribed to the Google Groups
ok i'm getting a sense of a chicken egg, where i'm the chicken.. and the
egg is the request context, let me try overview the way i see it:
define an interface extending request context, said interface will various
dao like method , like RequestProxy getById(int) and RequestVoid)
persist
11 matches
Mail list logo
