RequestFactory serialization with concrete classes

[isern]

Hi fellas,

I was wondering if there's a chance that a concrete POJO could be used
as an EntityProxy when serializing a graph via the RequestFactory
framework.

I mean, for most of the cases it works okay as an interface, but
sometimes it'd be nice if I could put some client logic on those
"objects" so that I can encapsulate client specific behavior in there
or even use polymorphism.

I support the idea that client and server objects should be separate
and distinct, but sometimes it's ugly/not very testable to put all the
client logic in "Util" clases or components instead of the object
itself.

I'd rather not use a plain raw RPC DTO because I'd miss the magic that
RF does when merging client-side to server-side entities, that works
extremely well.

Any ideas would help

Thank you!

[Ryan McFall]

I think this would be nice also; there are several "helper" methods
that I'd like to have available on the client that are already
implemented on my server objects.

The requirement that the client proxies extend EntityProxy precludes
writing helper classes that can operate on both client and server
instances, since there's no way there can be a common interface that
these objects implement. I guess the server side POJO can implement
the proxy interface, but this then requires that it implement a
stableID method, which doesn't really make sense. I guess it would
never be called, but it pollutes the interface to the server-side
objects.

Ryan

[Thomas Broyer]

How about (not tested, might not work, I've had a few issues with generics and RequestFactory):

interface Foo<B extends Bar> { get/setSomeProperty(String); get/setBar(B); }

interface Bar { get/setSomeProperty(int); }

interface FooProxy extends Foo<BarProxy>, EntityProxy { }

interface BarProxy extends Bar, ValueProxy { }

class FooImpl implements Foo<BarImpl> { ... }

class BarImpl implements Bar { ... }

and have all your "helper methods" work with the Foo and Bar interfaces? (and factories if you have to create instances)

[isern]

Thank you guys for your replies, they were very useful.

I tried the shared interface solution proposed by Thomas and it works
great, so the main problem (code replication) is seemingly solved.

The fact that the object state and behavior are separated is still
something that could be improved but I can live without that. I hope
that it gets implemented in the upcoming releases.

Would you say it would be useful? Following the OO idea, I imagine
that some operations could be encapsulated so that the caller doesn't
have to know the specifics about the object. Like, for example, if I
say that I want to edit(), it returns a Dialog that depends on the
object type and workflow state (actually, that's my present use case)

And for simple CRUDs the current interface approach is perfect.

Best,

Juan