Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Discussion" <users@myfaces.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <483FBA47.1060001@chello.at>
Date: Fri, 30 May 2008 10:26:47 +0200
From: "simon.kitching@chello.at" <simon.kitching@chello.at>
User-Agent: Thunderbird 2.0.0.0 (X11/20070418)
MIME-Version: 1.0
To: MyFaces Discussion <users@myfaces.apache.org>
Subject: Re: duplication POJO and JSF beans
References: <b82b8560805300110l731c312bve189ea05c724d0d2@mail.gmail.com>
In-Reply-To: <b82b8560805300110l731c312bve189ea05c724d0d2@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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