On Tue, 16 Mar 2010 06:33:18 -0300, Jim O'Callaghan
<jc1000...@yahoo.co.uk> wrote:
I'm also interested in why this is not a good approach - the plumbing
may be a little unwieldy but general usage is very convenient. Are there
performance issues with the approach?
It uses a list to implement ValueEncoder's toValue() method, when you just
need to load one object. You know what its id is, so why loading a list of
objects when you know exactly which one you need? In other words, you're
loading n objects from the database and using just one of them. In
addition, using a class transformation for this is a way too complicated
way of doing something simple.
What I recommend:
1) For SelectModel, use the OptionModelImpl and SelectModelImpl classes.
They're internal, I know, but I'm planning to contribute some non-internal
implementations of SelectModel and OptionModel.
2) For ValueEncoder, implement one for each entity class based on its
primary key property or, if you're using Tapestry-Hibernate, one
ValueEncoder implementation is automatically added to the
ValueEncoderSource service.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
