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.
On Wednesday, July 24, 2013 1:26:31 PM UTC+2, salk31 wrote:
>
> 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.
>
> On Wednesday, July 24, 2013 12:20:11 PM UTC+1, GWTter wrote:
>>
>> 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.
>>
>> On Wednesday, July 24, 2013 9:24:40 AM UTC+2, salk31 wrote:
>>>
>>> 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.
>>>
>>> On Wednesday, July 24, 2013 12:20:35 AM UTC+1, GWTter wrote:
>>>>
>>>> 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
>>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
