On Sep 15, 2005, at 21:26, Andrus Adamchik wrote:
> I am trying to find an answer to another design question that is
> related to this discussion. So ... if we have client classes on the
> server, this is redundant and complicates deployment. If we don't,
> how do we reuse custom logic on both client and server? By calling
> a remote method? This would suck for simple things, like combining
> a few properties to get a derived value and such... I am still
> looking for a clean way of doing that.
This is the way I was thinking..:
* The objects and the object graph are edited on the client side
using the client classes.
* The client calls commit
* The client logic sends the diff to the server context
* The server propagates the info to the server classes. If person's
fullName changed on the server, call Person.setFullName with the new
value on the server.
* The server context commit
Same thing should happen on query. I think the result of the query
should be put into the normal server classes (like _Person and
Person) and the serializer (xml, hessian, whatever) should issue all
the get* methods on the objects.
It should be possible for the app developer to have some logic in the
server classes and some other logic on the client classes.
I do not know if this is the way to do it. Just some thoughts...
- Tore.
This archive was generated by hypermail 2.0.0 : Thu Sep 15 2005 - 16:17:31 EDT