> By the way, you can use Hibernate cache features to deal with that instead of implementing it yourself.
Ahh ... I knew this ... but it is something I need to read up on. > Again: each ValueEncoder method is invoked in different requests and it's not a good idea to put object lists in memory (session). Ok - I saw them both (model and encoder) retrieved at page load but I missed its invocation on submit. This approach makes sense to me then. > You're doing (bad, IMHO) premature optimization, and it is the root of all evil. (I just love this quote :)). Ohhh ..... well thanks for the warning! There are some obvious baddies I try to avoid right away and this looked like double work - but I need to get my head around hibernate caching a bit more. > 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. Thanks for helping illuminate the path. Thanks, -Luther On Wed, Mar 4, 2009 at 2:00 PM, Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > 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 > >
