[Arp] Arp 3 Plans

[Aral Balkan]

I just realized one important thing that I forgot:

Business Delegates will need success and failure methods for remote 
methods. Only model updates and other business logic should be carried 
out here. The view will be notified of model updates via the bindings 
and not through explicit invocation of a public method as in Arp 2. 
(This does not remove the need for success and failure methods on the 
view, which are used purely to implement view logic in response to the 
success/failure of a request.)

Is there room for intelligent defaults here? Ideally, it would be great 
if the TO could somehow automatically be mapped to a model update on the 
client (renaming VOs to TOs -- transfer objects -- might make their 
purpose clearer. I know there's confusion sometimes in Arp about the 
role of VOs and they are commonly used -- incorrectly -- as model data.) 
I'm not sure though about real-world use cases for this. In the majority 
of calls, you would want to handle the error condition in a custom 
manner anyway so that would mean at least a failure handler. On the 
other hand, the prospect of having truly no-code remote-method proxies 
would cut down a lot of code and DRY this baby up even more.

Thoughts appreciated :)

Take care,
Aral

gilles Bertrand wrote:

>This looks great aral, ill read into it later but great thinking..
>
>Gilles
>  
>
<snip>