Regarding the LoadFromDbServiceLayer: This is exactly what I was looking for. Thanks.
Regarding pluggable mappers: In our applications, for each entity the actual relationship with other object(s) is by encapsulating the instance of others (typical for ORM layer). But in our DTOs in most cases the Id/Business Key is sufficient instead of the whole object. In projects not using RF, (ie RPC) the service layer is using only DTOs and the delegate layer is working on entities. Here the entity to DTO conversion and vice-verse is being done using Dozer<http://dozer.sourceforge.net/> . When it comes to RF, - I should either make the service layer to work with DTOs and then create proxies. (double work) or - I should use something like 'LoadFromDbServiceLayer' for each such property. In short, the current impl of RF supports Proxies (which i believe to play the role to DTOs) which are only the mirror of the entities. It is just like a proxy layer that is same as entity layer. Thanks, On Fri, Apr 20, 2012 at 3:53 PM, Thomas Broyer <t.bro...@gmail.com> wrote: > > > On Friday, April 20, 2012 11:45:48 AM UTC+2, -sowdri- wrote: >> >> As you were doing in your project, this kind of supplying a custom mapper >> for proxy to entity mapping could be a common requirement. > > > I sincerely doubt it. > > We made very bad choices upfront that led us to this situation (in brief: > we have very large entities with many embedded objects –equivalent to > @Embedded in JPA/JDO– several levels deep, and we wanted to expose them as > EntityProxies, so we have to craft fake IDs for the embedded objects –ID of > the entity + property-path to the embedded– and use "wrapper" objects as > domain objects to pair the embedded objects and their fake IDs, and this is > why we need that "transaltion" to take place: our service methods take > proxies on the client-side, and wrappers on the server-side; we validate > things at build time –similar to the ValidationTool– and generate a > DeofuscatorBuilder, instead of doing expensive computations at runtime to > resolve the domain method) > This is a very singular situation. > > We do many other things using ServiceLayerDecorators that are very easy: > "implementing" fake properties, handling authorization on service methods, > and doing dependency-injection on Locators and ServiceLocators (getting > them out of our Guice Injector) > > >> Any thoughts on whether it would be appropriate to file a bug requesting >> this feature in RF? >> > > I don't know what kind of feature you're asking for, but it's likely to > not actually be needed. > If you do think there's a missing feature though, let's discuss it! (here > or on the GWT-Contributors group) > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-web-toolkit/-/IZmqP40Rb2UJ. > > 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. > -- -sowdri- -- 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.
