[GWT2.8] RequestFactory lambda support

[Kay-Uwe Janssen]

Hello there,

i wonder if there are plans to allow developers to use lambdas/method references for requestfactory.

my idea was that there could be some overloaded versions of fire(Receiver<T>) and to(Receiver<T>) that accept 1-3 lamdbas (4 if the deprecated onViolation should be supported here too).

e.g

fire(Receiver<T>) // the original

fire(SuccessReceiver<T>) // only the success callback

fire(SuccessReceiver<T>, FailureReceiver) // the success + failure callback

fire(SuccessReceiver<T>, ConstraintViolationReceiver) // the success + ConstraintViolation callback

fire(SuccessReceiver<T>, FailureReceiver, ConstraintViolationReceiver) // the success + failure + ConstraintViolation callback

same for to() of course.

the implementation could be something like: all lambda supporting methods call the one with the Receiver parameter with an assembled Receiver that forwards its calls to the corresponding lambda.

[Manuel Carrasco Moñino]

Hi Kay,

It makes sense to me if it does not break old code, could you take the time to make those modifications and send a patch? 

Thanks

- Manolo

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/b33b86ac-e2e9-4e9d-a6d5-a4efdfa9117e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jens]

I am pretty sure APIs will be enhanced for better lambda use over time but that will probably happen after a 2.8 release. 

Given your concrete example it might be cleaner to let fire() return an object that you can use to register callbacks on, similar to a Promise / CompletableFuture. That avoids having lots of overloads of the fire() method with all kinds of parameter combinations.

IMHO readability also improves with such an object because it communicates pretty clearly which request state maps to which lambda, e.g. updatingPerson.onSuccess(<lambda>), updatingPerson.onConstraintViolation(<lambda>). Also you can pass around that instance which can be beneficial and, if supported, possibly attach N callbacks to one request state.

-- J.

[James Horsley]

Love the idea of more lambda friendly RF methods but completely agree with Jens on the Promise/CompletableFuture approach being preferable.

--

You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/4d40216a-204e-4e77-83a1-d8a00e539eea%40googlegroups.com.