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 Friday, April 20, 2012 3:36:44 PM UTC+5:30, Thomas Broyer wrote: > > > > On Friday, April 20, 2012 11:44:02 AM UTC+2, -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? >> > > class LoadFromDbServiceLayer extends ServiceLayerDecorator { > @Override > public Object getProperty(Object domainObject, String propertyName) { > if (domainObject instanceof SomeDomainObject && > "someProperty".equals(propertyName)) { > // make db call and return the value > } > return super.getProperty(domainObject, propertyName); > } > } > > Note that this depends on the domain type, you don't know the proxy type > here (as, technically, the same domain object instance can be exposed as 2 > distinct proxy instances). > > If you want to depend on the proxy type instead, make it "incompatible" > with the domain type (change the property name on the proxy and mark it > with @SkipInterfaceValidation), so that you can check for that name in the > ServiceLayerDecorator. > -- 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/-/0DwylQerG6gJ. 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.
