On 05/20/2011 02:24 AM, Thiago H. de Paula Figueiredo wrote:
If you're using tapestry-hibernate, the ValueEncoder is automatically added for every of your mapped entity classes. It's implementation is simple: it uses the primary key field of the object and converts it to a String and vice-versa. That's what you should do in your hand-coded ValueEncoders too.
Yes we use tapetstry-hibernate and this is all automated which is excellent. So if you have entity classes like this.
Person  ----> Country
And if you are creating a form based on Person, it is really simple to create a list box with the SelectModelFactory.

But imagine a situation like this:
                                       /------>ClassB ------> ClassE
       ClassA ---------> ClassC----> ClassD

Then when filling A you have to select some item from C (which sometimes by nature is not a strong entity, but a weak one and it depends on B, D, E). Here SelectModelFactory does not help by itself, because choosing just one property is not enough. The database is heavily normalized and rather complex and the user will not be very clear if I only output the id or title of C

So I do this:
<t:selectObject list="listOfAs" value="a" label=" literal: c.b.e.title '\s' c.d.title '\s' c.title ">

Now this is great! I like it the way I do it because it is very easy and it is readable. I programmed the same use-cases with JSP and plain SQL in the past and this is many many times faster and of course easier.

But what is the catch?
Is there any?
Is it a bad approach (although very easy)? Do I waste too much memory? Too much lazy connections to the database?

I got worried after reading your comments on the various approaches to this on the Wiki, because 95% of our forms require such programming.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to