Igor, I don't understand the optimal use of the different repeaters list views in different scenarios well enough yet, so I would be greateful if someone could provide a link for more documentation.
As far as I understand, though, refreshingview.setreuseitemstrategy() is about re-using items - it is all about models. I am thinking about re-using the rendering component for ALL items in the collection. That would not require any strategy. And I would want this to work with database driven collections, so far I have used DataProvider with LDMs. What needs to be done to get re-used components in this scenario? Bernard On Fri, 26 Mar 2010 16:41:11 -0700, you wrote: >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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
