Re: RequestFactory-ValueProxy in conjunction with RequestFactoryEditorDriver vs. SimpleBeanEditorDriver

On Tuesday, August 30, 2011 11:22:47 AM UTC+2, daniel wrote:

hi,

I'm currently playing around with RequestFactory and the EditorFramework.

I use requestfactory as simple rpc-mechanism (meaning I currently just use ValueProxies not EntityProxies) using the following service:

public class OrderService {
   public static String placeOrder(OrderDescription description) {
        return "placeOrderInvoked";
   }
}

Now I want to use an Editor to "fill" the OrderDescriptionProxy accordingly. In on-submit, I will then call the context.placeOrder()-servicemethod accordingly. I wonder what is the best/correct approach to take (both do work)?

Approach 1:
Using RequestFactoryEditorDriver. I will store a reference to the OrderDescriptionProxy as an instance-variable in the activity.

in start-activity:
* driver = view.createEditorDriver (which returns a RequestFactoryEditorDriver)
* proxy = context.create(OrderDescriptionProxy.class)
* driver.edit(proxy, context)
* view.setDelegate(this)

in on-submit (called from view on presenter):
* driver.flush()
* context.placeOrder(proxy).fire(new Receiver<String>() {
            @Override
            public void onSuccess(String response) {
                GWT.log("Got response: " + response);
               
            }
        });


Appraoch 2:
using SimpleBeanRequestEditorDriver. I just create a OrderDescriptionProxy and give it the the SimpleBeanRequestEditorDriver.edit()

in start-activity:
* driver = view.createEditorDriver2();
* OrderDescriptionProxy proxy = context.create(OrderDescriptionProxy.class);
* driver.edit(proxy);
* view.setDelegate(this);

in on-submit (called from view on presenter):
* OrderDescriptionProxy proxy = driver.flush();
* context.placeOrder(proxy).fire(new Receiver<String>() {
            @Override
            public void onSuccess(String response) {
                GWT.log("Got response: " + response);
               
            }
        });


Both approaches seem to work. Which one is the better/correct way of doing this.

I'd go with Approach 1, or possibly approach 3:

in start-activity:

* driver = view.createEditorDriver (which returns a RequestFactoryEditorDriver)

* OrderDescriptionProxy proxy = context.create(OrderDescriptionProxy.class)

* context.placeOrder(proxy).to(new Receiver<String>() {

            @Override

            public void onSuccess(String response) {

                GWT.log("Got response: " + response);

                

            }

        });

* driver.edit(proxy, context)

* view.setDelegate(this)

in on-submit (called from view on presenter):

* driver.flush().fire();

 

@Appraoch1: because I'm curious
when I using approach1 and I do the following in on-submit:
* driver.flush.fire();

on the server i receive the following request:

{"O":[{"T":"gwtapp.client.ui.invoice.order.rf.OrderDescriptionProxy","P":{"customerId":"cid","vehicleLicensePlate":"plate","productCode":"pcode"},"C":2,"R":"1","O":"PERSIST"}]}

and this response is returned:

{"O":[{"T":"gwtapp.client.ui.invoice.order.rf.OrderDescriptionProxy","R":"1","C":2}]}

Remeber I call driver.flush().fire() which will transmit a ValueProxy not anentityProxy. What is happening here - will there an new instance of OrderDescription be created on the server side??

A new instance will be created, its setCustomerId, setVehicleLicensePlate and setProductCode will be called, then nothing will be done because you didn't queue any invocation. 

 

Actually I was expecting an exception?

I think you'd have one with an EntityProxy because it wouldn't have been persisted (you wouldn't have an exception if the EntityProxy weren't created on the client using RequestContext.create, but previously retrieved from the server).

But with ValueProxies, there's really no reason to throw an exception: you send a proxy with a bunch of operations and no invocation, why would it throw? (because there's no invocation? well, on the other hand, running the code you asked to be run just works without throwing, so...)

(I mean, it's not illogical, it's just a choice of implementation IMO)

--
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/-/Ec8JbTKb-ccJ.
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.