You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Anton Gavazuk <an...@gmail.com> on 2008/05/30 10:10:27 UTC
duplication POJO and JSF beans
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.
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.
So the only one way which I see now - create new POJO for UI which
extends CorePojo and adds needed fields.
So my question is:
does someone come accross with same situation? How it can be resolved?
Re: duplication POJO and JSF beans
Posted by Anton Gavazuk <an...@gmail.com>.
James,
Hmmm, I thought about composition, but
functions require entities as parameters:
BIFMAMAINTERFACE.blablabla(POJO1, POJO2)
so with composition it would be:
BIFMAMAINTERFACE.blablabla(JSFBEAN.getWrapped1(),
JSFBEAN.getWrapped2())
Thank you for answer
2008/5/30 James Clinton <Ja...@patsystems.com>:
> Why don't you wrap or decorate the entity(pojo) where required?
> Personally in this situation I would favor composition over inheritance.
>
> -----Original Message-----
> From: Anton Gavazuk [mailto:antongavazuk@gmail.com]
> Sent: Friday, May 30, 2008 9:10 AM
> To: MyFaces Discussion
> Subject: duplication POJO and JSF beans
>
> 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.
>
> 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.
> So the only one way which I see now - create new POJO for UI which
> extends CorePojo and adds needed fields.
>
> So my question is:
> does someone come accross with same situation? How it can be resolved?
>
> DISCLAIMER: This e-mail is confidential and may also be legally privileged. If you are not the intended recipient, use of the information contained in this e-mail (including disclosure, copying or distribution) is prohibited and may be unlawful. Please inform the sender and delete the message immediately from your system. This e-mail is attributed to the sender and may not necessarily reflect the views of the Patsystems Group and no member of the Patsystems Group accepts any liability for any action taken in reliance on the contents of this e-mail (other than where it has a legal or regulatory obligation to do so) or for the consequences of any computer viruses which may have been transmitted by this e-mail. The Patsystems Group comprises Patsystems plc and its subsidiary group of companies.
>
>
RE: duplication POJO and JSF beans
Posted by James Clinton <Ja...@patsystems.com>.
Why don't you wrap or decorate the entity(pojo) where required?
Personally in this situation I would favor composition over inheritance.
-----Original Message-----
From: Anton Gavazuk [mailto:antongavazuk@gmail.com]
Sent: Friday, May 30, 2008 9:10 AM
To: MyFaces Discussion
Subject: duplication POJO and JSF beans
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.
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.
So the only one way which I see now - create new POJO for UI which
extends CorePojo and adds needed fields.
So my question is:
does someone come accross with same situation? How it can be resolved?
DISCLAIMER: This e-mail is confidential and may also be legally privileged. If you are not the intended recipient, use of the information contained in this e-mail (including disclosure, copying or distribution) is prohibited and may be unlawful. Please inform the sender and delete the message immediately from your system. This e-mail is attributed to the sender and may not necessarily reflect the views of the Patsystems Group and no member of the Patsystems Group accepts any liability for any action taken in reliance on the contents of this e-mail (other than where it has a legal or regulatory obligation to do so) or for the consequences of any computer viruses which may have been transmitted by this e-mail. The Patsystems Group comprises Patsystems plc and its subsidiary group of companies.
Re: duplication POJO and JSF beans
Posted by Anton Gavazuk <an...@gmail.com>.
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 <si...@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
>
>
Re: duplication POJO and JSF beans
Posted by "simon.kitching@chello.at" <si...@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