Em Wed, 04 Mar 2009 16:50:21 -0300, Luther Baker <lutherba...@gmail.com>
escreveu:
... my encoder implements this method:
public T toValue(String clientValue)
So in my case, the encoder needs data from the database. I've spent cpu
cycles in getModel() to pull a list of items. It seems like I should
leverage that list when I hydrate the object back from it's screen
representation to an actual object ... no?
No. toValue() is only invoked when the form is submitted. The list loading
happens in another request. It is not a good idea to keep the list on
memory bacause each user session would have an enormous size. By the way,
you can use Hibernate cache features to deal with that instead of
implementing it yourself.
I guess - I could inject a dao or connection to the database into the
ValueEncoder - but on first glance, that seems like overkill ...
It is not. Service injection is very cheap. And tapestry-hibernate already
provides a ValueEncoder for each entity class.
I just need to get comfortable with it. Iv'e got the list right there. It
can't have changed eh?
You're doing (bad, IMHO) premature optimization, and it is the root of all
evil. (I just love this quote :)).
To sum up, the main issue here is that the object I'm 'toValue'ing
exists in the dbase (and in the model). The Wiki example for
GenericSelectModel
queries the database two times but I think it is redundant to do so.
Again: each ValueEncoder method is invoked in different requests and it's
not a good idea to put object lists in memory (session).
But again, if thats what the framework wants me to do - I'll work with
it.
The framework does not tell you what to do: it just encourages you to
follow some proven paths, but you can choose to not follow them.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org