I have ended up with custom DTO classes and Hibernate projections. Although the resulting code looks far from elegant, it's extremely fast, compared to 'normal' retrieval using lists, without paging (especially for lists with hundreds of records of course).
On Mon, Jan 5, 2015 at 1:39 PM, Thiago H de Paula Figueiredo < thiag...@gmail.com> wrote: > On Fri, 02 Jan 2015 06:45:30 -0200, Ilya Obshadko <ilya.obsha...@gmail.com> > wrote: > > I'm trying to implement a Grid data source optimized for database >> retrievals (with paging support). Basically it's derived from >> HibernateGridDataSource from Tapestry distribution, and provides support >> for complex Criteria queries: >> https://gist.github.com/xfyre/ecb36a9173aed6a37f14 >> >> However, there is a problem with sorting. >> >> Provided BeanModel implementation doesn't support nested properties; that >> is, I cannot use properties of child Hibernate entities: <t:grid >> include="property1, child1.property1, child2.property2" .../>results in >> error. >> > > Remember you're passing a Class instance for BeanModelSource, so the > properties which are actually recognized as the ones provided by the class > you passed, not subclass ones. That's how Java and strongly-typed languages > work: if you have a class C and a subclass S, if you ask Java reflection > classes or BeanModelSource to provide a list of properties of C, only > properties from C will appear. > > Initially I had a workaround of having helper getter methods in >> parent entity class, so it looked like <t:grid include="property1, >> child1Property1, child2Property2" .../>. It worked, but when I'm trying >> to use database-backed Grid data source, there's an error with sorting >> (because sorting is performed on database level and obviously root entity >> of the query doesn't contain database properties specified in Grid. >> > > You receive the name of these properties, so it's up to your code to > handle this kind of situation (synthetic BeanModel properties). > > I agree with Chris, whose opinion matches what Howard has been saying for > a long time in the Tapestry mailing list: the BeanModel classes and > components are meant to be used as a starting point, as scaffolding, as > tools to have something working quickly, but they're not supposed to handle > all scenarios by themselves. > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.com.br > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Ilya Obshadko
