RequestFactory .with() to access non-relation (primitive) properties?

[GWTter]

Hi all,

I have a String username field on a user entity which I'd rather not populate whenever I request it which is why I have not defined the getter in the EntityProxy. This works fine, however there are some instances where I would like to have RequestFactory populate that string field when I retrieve the object. 

I know the documentation says that .with() is to be used to retrieve relations and in my tests I found that .with("username") does not pull it down either. Now I don't think it is possible but I wanted to make sure before implementing it another way that it  is indeed not possible. It would be much cleaner to just be able to retrieve that property using .with() and being able to use the same request. 

Does anyone have an idea?

Thanks in advance,

-Seth

[salk31]

I'm pretty sure by default you can't. If you feel the urge to fiddle you could do something in ServiceLayerDecorator.getProperty that picks up on some extra state with the request.

I know the requirement you mean though. Some extra layer of fetch profile. Not sure it would be worth the extra complexity though.

We do something similar though for security. We have @PreAuthorize on getters and setters and our ServiceLayerDecorator returns nulls when the user is not allowed to read that property and ignore any requests to write to those properties.

[GWTter]

Thanks for the reply.

Yea :/, the work involved in fiddling with the service layer decorator and server-side RF at that level currently outweighs the benefit for my need which is what I was avoiding. I think if I fiddled at that level I might just end up making the .with() work with primitives also. It would be a nice to have as the property resolution already does this for the proxy, I can't see the extension of .with() to include this as being much more complex.

And thanks, an annotation like PreAuthorize is something nice to keep in mind if you're going to go into the decorator. The other way I thought of doing it would be to have 2 different entity proxies for the same entity. That way you could keep and use 2 different property definitions/contracts for the same entity and use the most appropriate one. This would also keep the code cleaner and more cohesive as your functionality can be written around the appropriate contract, at least in my opinion.

[salk31]

If you try the multiple Proxies approach could you report back to the group? Be interesting to hear if it works out nicely. Proxies being allowed to have their own inheritance tree etc seems powerful but I'm quite sure for good or evil.

[GWTter]

Will do. My approach would involve distinct proxies since I don't think RF allows for inheritance on EntityProxys even if they both have @proxyfor defined because it looks for the methods defined exactly on the proxy (it definitely won't currently let you do it server-side with your locators). This is the only drawback I can see using this approach since you'd have to redefine fields that would be granted with inheritance. But I'll definitely give both a try again.

[Thomas Broyer]

On Wednesday, July 24, 2013 1:39:19 PM UTC+2, GWTter wrote:

Will do. My approach would involve distinct proxies since I don't think RF allows for inheritance on EntityProxys even if they both have @proxyfor defined because it looks for the methods defined exactly on the proxy (it definitely won't currently let you do it server-side with your locators). This is the only drawback I can see using this approach since you'd have to redefine fields that would be granted with inheritance. But I'll definitely give both a try again.

Inheritance of proxies works well; RequestFactory even supports polymorphism (o in your case you'll want to test which exact proxy RF returns, and possibly split the common properties out to an interface used as the super-interface for 2 distinct, unrelated proxies)

What won't work currently are generics and overrides with co-variant return types (see https://gwt-review.googlesource.com/#/c/3831/2/user/test/com/google/web/bindery/requestfactory/gwt/client/RequestFactoryGenericsTest.java for a "gory" test), but it otherwise works very well.

[Thomas Broyer]

BTW, see “Polymorphic type-mapping rules” in http://www.gwtproject.org/doc/latest/DevGuideRequestFactory.html#transportable

And I'd even say that not only this is a supported use-case, it's actually the approach I'd recommend. 

[GWTter]

Hi Thomas,

This is great, I was hoping this was the case. I knew polymorphism worked well but I wasn't sure whether you could define EntityProxy super classes and that RF would still be able to find the super class properties from the child proxy without having to explicitly define them in the child EntityProxy. Thanks for the good news, RF just got way better.