Simon,
Cool
I havent known about this library - it can be a solution for the subject
About Spring - I dont like spring ) so I dont want to use it - I prefer Guice
Thank you very much!
2008/5/30 [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Anton Gavazuk schrieb:
>> Hi all,
>>
>> I'm using JPA as persistence layer, and one of my modules contains
>> more then 50 entities.
>> Almost all of those entities (POJO) I must somehow show in UI.
>> But in UI some POJOs should have extra fields - value for this fields
>> is generated according to business logic, so the value is not a part
>> of actual entity.
>>
>
> Yep, common problem.
>> Simple Example
>>
>> CorePojo
>> int a;
>> int b;
>> int generatedValue = businessFunction.(a,b);
>> ....
>>
>> I dont like approach when this "generated" value is being added to
>> core POJO with @Transient mark - on other hand I dont' want to create
>> in my JSF application copy of every original POJO with extra fields.
>>
> Yep, that solution is pretty ugly.
>> So the only one way which I see now - create new POJO for UI which
>> extends CorePojo and adds needed fields.
>>
> The problem with creating a subclass of the real persistent pojo is that
> these "ui-specific" pojos must be different instances from the ones
> dealt with by the ui, so data must be copied back and forth between the
> persistent pojos and the ui versions.
>> So my question is:
>> does someone come accross with same situation? How it can be resolved?
>>
>
> The solution I've most commonly used is to write wrapper classes that
> add the UI-specific methods, ie something like:
> public class UICorePojo {
> public CorePojo getCorePojo() {...} // the persistent object
> public int getGeneratedValue() {...} // the "added" functionality
> }
> then use EL expressions like
> #{foo.corePojo.a}
> #{foo.generatedValue}
>
> Unfortunately this does mean the EL is "aware" of the difference between
> the "real" methods and the added ones.
>
> On one project I used, CGLIB was used to transparently generate a proxy
> class that effectively did what the above code does, but also made the
> CorePojo methods available on the generated proxy. Then the EL can
> consistently access the proxy, with the method being delegated to the
> appropriate handler. I suspect that using Spring's AOP support could
> make this quite easy to do.
>
> Regards,
> Simon
>
>