yes, if you only use bookmarkable links you can remove items after they render.
but like i said, component frameworks are not really made to handle modelling repeaters with 10K rows. each component has overhead, so when you are trying to render 10K*~10 components per row you end up with 100K components. in these (extremely rare cases) you should drop down to using raw html to eliminate component overhead so instead of 100K components you only have one. you have to do a bit more work yourself, but at least you still retain encapsulation. -igor On Fri, Nov 21, 2008 at 9:39 AM, Martin Makundi <[EMAIL PROTECTED]> wrote: > Would it help using Bookmarkable links? > > ** > Martin > > 2008/11/21 Igor Vaynberg <[EMAIL PROTECTED]>: >> On Fri, Nov 21, 2008 at 9:18 AM, Ralf Siemon <[EMAIL PROTECTED]> wrote: >>> Thanks for the advice. Unfortunately we cannot do this here, because the >>> ListViews contain Link components for user interaction. >> >> you can generate a link yourself easily, let your custom listview >> implement ILinkListener and call urlfor(ILinkListener.INTERFACE) on >> the component which will generate the url. than append the id to it >> and you are done. >> >>>This worked, but unfortunately the links did not work >>> anymore, because there were no link components on the page left ... >> >> ^ and now you know why the items are kept :) >> >> >>> >>> Ralf. >>> >>> >>> Igor Vaynberg wrote: >>> >>>> if you are planning on displaying 1000 rows per page, which is quiet >>>> uncommon for webapps, you should produce output as raw html instead of >>>> using listview and adding components inside. >>>> >>>> -igor >>>> >>>> On Thu, Nov 20, 2008 at 7:15 AM, Ralf Siemon <[EMAIL PROTECTED]> wrote: >>>>> >>>>> Hi, >>>>> >>>>> we have recently launched our new Wicket-based website, and now we are >>>>> experiencing that the memory consumption of the website is very high, so >>>>> that it crashes the site regularly. >>>>> >>>>> When profiling the application server, we found out that there are HTTP >>>>> sessions that consume up to 2 MB of memory, mostly because there are very >>>>> large ListViews with up to 1000 entries, where each entry consumes about >>>>> 2 >>>>> KB. >>>>> >>>>> Our preliminary solution is to limit the size of those ListViews to a >>>>> maximum of 50 entries, but even in those cases the session size is still >>>>> at >>>>> about 200 KB, which seems quite large to us. >>>>> >>>>> I know that there have already been some discussions about memory >>>>> consumption in Wicket due to the fact that the whole Page object of the >>>>> last >>>>> visited page is stored in the session; but what I'd like to know is: Have >>>>> you experienced session sizes in a comparable magnitude, or are we doing >>>>> something wrong? Or is this something we have to live with when using >>>>> Wicket? >>>>> >>>>> We are using Wicket 1.3.5. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Ralf. >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
