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 On Jun 16, 10:10 pm, isern <juanis...@gmail.com> wrote: > 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! -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
