repeaters support this, see listview.setreuseitems() and refreshingview.setreuseitemstrategy()
-igor On Fri, Mar 26, 2010 at 1:50 PM, <b...@actrix.gen.nz> wrote: > But why in repeating views are the components duplicated for each row? > Wicket should re-use the components - one instance for each row could > do all the rendering. Not one instance for each row which is a waste. > > Caching is a different concept as it also preserves the data which is > not wanted in repeaters unless one wants to cache the whole > collection. > > Bernard > > > On Fri, 26 Mar 2010 06:50:24 -0700, you wrote: > >>the recommended way to handle this would be to cache the data not the >>generated html >> >>-igor >> >>On Fri, Mar 26, 2010 at 1:11 AM, Martin Sachs <sachs.mar...@gmail.com> wrote: >>> We have a lot of Repeating views, which containing a lot of components, >>> which also contains repeatingviews. >>> >>> To know would should be rendered, we load some hopefully small >>> (listsizes, objectbyId, ...) datas from DB in the constructor and/or in >>> onBeforeRender and in isVisible. You are right, this is not a >>> recommented way. Most of the time is database-loading and wicket has no >>> performance-problem for us. We profile our application and never found >>> wicket-components as hotspots. >>> >>> One reason for loading some data in contstructur or onBeforeRender is to >>> prevent creating huge hierarchies. This is faster than override >>> isVisible(), since isVisible would called more than one times. >>> >>> For our usecase the responsetime is much faster with HTML-Caching, >>> because the Database-calls are minimized. We save the time for creating >>> componentshierarchies (all three categories) with loading data. >>> >>> >>> Martin >>> >>> Jeremy Thomerson schrieb: >>>> >>>> On Wed, Mar 24, 2010 at 3:26 AM, Martin Sachs <sachs.mar...@gmail.com >>>> <mailto:sachs.mar...@gmail.com>> wrote: >>>> >>>> hi, >>>> >>>> we need caching of components, since the construction of huge >>>> hierarchies is not cheap. The rendering ist fast. We cache the >>>> rendered >>>> HTML of a hole component via a beheaviour and write them on the next >>>> requests into a Label (unescaped). So instead of creating the complete >>>> hierarchie on every request, we create a much smaller one. But you >>>> must >>>> check, that the cachable components are stateless. Also we have JQuery >>>> for client-effects in this components, this would also be cached. >>>> >>>> The performance is much better with that: approx. 10-50 times better: >>>> 100ms with cache (the response time is not much depending on count >>>> of users) >>>> vs >>>> 1500 ms without cache depending how many parallel user >>>> >>>> >>>> A 15x gain is a big statement to make. Can you please break this >>>> 1500ms down into at least the following categories: >>>> >>>> 1 - time in IModel#getObject() and all child calls of this (IOW, >>>> loading data) >>>> 2 - time in constructor of components (without loading data in the >>>> constructor - hopefully you're not doing this) >>>> 3 - time in rendering of components >>>> >>>> That would be a much better number to give other users. I have NEVER >>>> seen where creating / rendering components could take 1400ms - unless >>>> you're doing something wrong like database calls in your component >>>> constructors. So, I suspect that most of that 1400ms (I would guess >>>> at least 1250ms) is in your model loading. >>>> >>>> The only time I've seen (or seen proof of) the component hierarchy >>>> actually be the slow part of a Wicket page is if you were displaying a >>>> repeating view of some sort with thousands of rows and each row had a >>>> bunch of components in it - leading to tens of thousands of components >>>> being built in the hierarchy. >>>> >>>> -- >>>> Jeremy Thomerson >>>> http://www.wickettraining.com >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>For additional commands, e-mail: users-h...@wicket.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
