[prev in list] [next in list] [prev in thread] [next in thread] 

List:       myfaces-user
Subject:    Re: duplication POJO and JSF beans
From:       "Anton Gavazuk" <antongavazuk () gmail ! com>
Date:       2008-05-30 9:29:23
Message-ID: b82b8560805300229r3b5530eax235266cb1beadc3a () mail ! gmail ! com
[Download RAW message or body]

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 simon.kitching@chello.at <simon.kitching@chello.at>:
> 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
>
>
[prev in list] [next in list] [prev in thread] [next in thread]