>> 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/-/F7QLW9H5E6cJ.
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.

Reply via email to