As you were doing in your project, this kind of supplying a custom mapper for proxy to entity mapping could be a common requirement.
Any thoughts on whether it would be appropriate to file a bug requesting this feature in RF? On Friday, April 20, 2012 3:14:02 PM UTC+5:30, -sowdri- wrote: > > >> For properties on proxies, you can actually simply mark them with > @SkipInterfaceValidation > > Actually the proxy interface is compatible with the entity. Just that for > one of the values, rather then using the value in the entity, i want to > make a db call to populate the value. That 's why I'm looking for the > actual place where this mapping is taking place, such that I can override > the default behavior only for this one entity. > > >> "implement" them in a ServiceLayerDecorator. > > Can you provide some more details regarding this? > > Thanks for the clarification, > > On Friday, April 20, 2012 3:01:05 PM UTC+5:30, Thomas Broyer wrote: >> >> >> >> On Friday, April 20, 2012 11:16:30 AM UTC+2, Thomas Broyer wrote: >>> >>> >>> On Friday, April 20, 2012 10:56:02 AM UTC+2, -sowdri- wrote: >>>> >>>> RF automatically maps entities to RF Proxy. Is there a way in which we >>>> could pass a custom mapper? >>>> >>> >>> Almost everything in RequestFactory on the server side is done by a >>> ServiceLayerDecorator; in this case >>> resolveClientType<http://google-web-toolkit.googlecode.com/svn/javadoc/latest/com/google/web/bindery/requestfactory/server/ServiceLayerDecorator.html#resolveClientType(java.lang.Class,+java.lang.Class,+boolean)>. >>> >>> The default implementation uses the DeobfuscatorBuilder that's being >>> generated by the ValidationTool (or equivalent annotation processor during >>> compilation); but you can very-well make your own DeobfuscatorBuilder >>> instead of relying on automatic generation (we do just that in our project, >>> because we have properties on our proxies with no direct equivalent on our >>> domain objects, the property is "implemented" by a custom >>> ServiceLayerDecorator overriding the getProperty and setProperty methods). >>> >> >> Oops, actually, our real need for the custom-generated >> DeobfuscatorBuilder is because we have methods on our RequestContext that >> do not match service methods directly (we have some kind of "translation" >> of the parameter and return types; this is really hackish so I won't go >> into the details here, but we have that translation of types taking place, >> so we have to mark our methods with @SkipInterfaceValidation, and instead >> of overriding resolveDomainMethod in a ServiceLayerDecorator, we generate >> the mapping in the DeobfuscatorBuilder). >> For properties on proxies, you can actually simply mark them with >> @SkipInterfaceValidation and "implement" them in a ServiceLayerDecorator, >> you don't need to tweak the DeobfuscatorBuilder as there's nothing to be >> "resolved" here. >> > -- 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/-/a_KZy16emX4J. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
