Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4F17B9FA.40808@telia.com>
Date: Thu, 19 Jan 2012 07:36:42 +0100
From: Tomas Stenlund <tomas.stenlund@telia.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: user@cayenne.apache.org
Subject: Re: Some more concrete questions about Cayenne
References: <C6479E749D884341B03A760750BB4D8E0479644F@eex1.hennig.local>
In-Reply-To: <C6479E749D884341B03A760750BB4D8E0479644F@eex1.hennig.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 01/18/2012 04:33 PM, Durchholz, Joachim wrote:

Well I just do that, answer a few of the questions:
> ...
>
>
> 2) How would one assign a "field type" with a field in a Cayenne Pojo?
>
> With "field type", I mean things like
> 123456789012345678901234567890123456789012345678901234567890123456789012
> - Associating textual representation with field contents, such as
> -- shorthands in the database table, Java enums internally,
>     longer texts on display
> -- or maybe shorthands in the database table, Java Strings internally,
>     longer texts on display
> - What Swing controls to use for displaying this data
>    ("Renderer" in Swing terminology)
> - What Swing controls to use for editing this data
>    ("Editor" in Swing terminology)
> - Validation info: valid ranges; probably a Java interface with
>    implementations that may or may not use RDBMS length/precision info
> - Possibly association with more than one field
>    (date/time in two fields but merged into one Java property)
>    (or still two Java properties, but validation etc. spans all of them)
>
> I see various possible approaches:
>
> 2a) The traditional Cayenne approach. Make the entity class a superclass, the business class a subclass. Entity class properties would have private members and protected getters/setters, the business class would then use a FieldType object to delegate public getters/setters to the protected getters/setters. (FieldType objects would be static and accept entity objects as parameters, so memory bloat isn't an issue. I'm using a similar construction in my current Hibernate infrastructure.)
> I'm a bit worried about the amount of boilerplate needed in the business class. In particular for the trivial cases where the DB field is simply handed through to the business logic (e.g. address fields where the end user should be able to put in pretty anything they choose as long as it fits the database field).
>
> 2b) Use delegation instead of subclassing. The issues are essentially the same, except the getters/setters of the entity class wouldn't have to be package-private or public instead of protected.
> Are there other issues that I should be aware of?
>
> 2c) Since I'm not too dependent on Modeler, I might merge entity and business class.
> I'm not sure that such a merge has any advantages; does anybody have seen this tried? Stories of failure and success equally interesting here.
> I have to admit I don't expect success, merging abstractions usually doesn't work well in the long term; losing the option to use Modeler's code generation later when we're more confident in it is a strong point agains that route, too. Still, I'd like to know how much water this assessment holds.
>
> 2d) Anything I haven't thought of. Different ways to use Java reflection, a Modeler option I'm not aware of that does all these things out of the box, whatever.
I have developed an application for cross country skiing competitions, 
time keeping, handling skiers, result service and so on using Cayenne. 
What I have discovered when it comes to UI I just stuck with the 
generated Entity class and added new getters/setters to fit my GUI 
whenever needed. Now in retrospect it looks somewhat ugly because my GUI 
layout now "pollutes" the Entity class. Either way it works, it is fast 
and works great with Cayenne instead of maybe going with a nicer design 
with inheritance one additional level as suggested in 2a (actually the 
cayenne getters/setters would be visible as well). It gives me both 
benefits and drawbacks. It is not my proudest design, but then again I 
does the job and I learned to use Cayenne and the GUI-frameowork at the 
same time.

Now something completely different, 2d.

For the GUI part, I'n not using Swing. I use Apache Pivot which I think 
works great with Cayenne. It binds the controls to the getters/settes 
directly into a Pojo (e.g. the cayenne entity object) and also have 
support for datamapping, which allows you to move the data conversion 
from the cayenne entity more towards the GUI instead (which I would like 
to have it, instead of in the entities). Your "own" GUI-code is minimal 
in each dialog/window. I think this is a quite a nice approach that you 
could look at. But then again, this is GUI and not Cayenne.

Cheers,

Tomas