Re: Large number components and redering time
If you want to avoid mixing HTML and Java, you could write your component with using a templating engine, such as Velocity or Freemarker. I believe there is wicket-velocity project somewhere that provides for example Panels that can render Velocity templates files. br, Juha On Thu, Feb 18, 2010 at 9:22 AM, d...@agentlab.de wrote: Hi, Igor Vaynberg wrote: i would imagine you would have the same problem even in a local environment such as swing... absolutely, I was just wondering what would be the best way to do it in Wicket... the solution is quiet simple, instead of using wicket components to model the table and the cell simply use a single component that writes out html for the entire table. That's the solution a friend of mine suggested as well since he had similar problems in ZK. I was reluctant since writing out HTML felt somewhat un-wicket-ish. But I think that's the way to go for this kind of situation... Thanks everybody for your suggestions and comments. J. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - 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
Large number components and redering time
Hi, I have a question on how to address a certain problem that arose in my current project: we have a two-dimensional array with a variable number of rows and columns (not exactly rocket science, I know) that needs to be rendered in an HTML table where each cell is currently represented by a wicket-Label. Now, in the production environment, the number of rows and columns gets quite large such that we have roughly 25.000 cells to render. This yields to the effect, that the rendering process for the component tree takes a lot of time: on my windows machine approx 7 seconds and, for some reason we have not found out about until now, on the integration machine (IBM server) around 45 seconds. Clearly, this is not acceptable. Now, my question is, how should we address this problem? Is the naive approach of using two nested ListViews and rendering each as component plain dumb? What would be the alternatives? Thanks for any help, J. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Large number components and redering time
Could you use a PageableListView or does that not fall within your business requirements? Josh -Original Message- From: d...@agentlab.de [mailto:d...@agentlab.de] Sent: Wednesday, February 17, 2010 12:08 PM To: users@wicket.apache.org Subject: Large number components and redering time Hi, I have a question on how to address a certain problem that arose in my current project: we have a two-dimensional array with a variable number of rows and columns (not exactly rocket science, I know) that needs to be rendered in an HTML table where each cell is currently represented by a wicket-Label. Now, in the production environment, the number of rows and columns gets quite large such that we have roughly 25.000 cells to render. This yields to the effect, that the rendering process for the component tree takes a lot of time: on my windows machine approx 7 seconds and, for some reason we have not found out about until now, on the integration machine (IBM server) around 45 seconds. Clearly, this is not acceptable. Now, my question is, how should we address this problem? Is the naive approach of using two nested ListViews and rendering each as component plain dumb? What would be the alternatives? Thanks for any help, J. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - 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
Re: Large number components and redering time
Hi! Did you jprofile where the time is spent? ** Martin 2010/2/17 d...@agentlab.de: Hi, I have a question on how to address a certain problem that arose in my current project: we have a two-dimensional array with a variable number of rows and columns (not exactly rocket science, I know) that needs to be rendered in an HTML table where each cell is currently represented by a wicket-Label. Now, in the production environment, the number of rows and columns gets quite large such that we have roughly 25.000 cells to render. This yields to the effect, that the rendering process for the component tree takes a lot of time: on my windows machine approx 7 seconds and, for some reason we have not found out about until now, on the integration machine (IBM server) around 45 seconds. Clearly, this is not acceptable. Now, my question is, how should we address this problem? Is the naive approach of using two nested ListViews and rendering each as component plain dumb? What would be the alternatives? Thanks for any help, J. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - 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
Re: Large number components and redering time
Surely a change in the use case would ease our lives, unfortunately we are migrating a legacy application to a new technology and the look and feel (if you could call it that) must be retained... J, Josh Chappelle wrote: Could you use a PageableListView or does that not fall within your business requirements? Josh -Original Message- From: d...@agentlab.de [mailto:d...@agentlab.de] Sent: Wednesday, February 17, 2010 12:08 PM To: users@wicket.apache.org Subject: Large number components and redering time Hi, I have a question on how to address a certain problem that arose in my current project: we have a two-dimensional array with a variable number of rows and columns (not exactly rocket science, I know) that needs to be rendered in an HTML table where each cell is currently represented by a wicket-Label. Now, in the production environment, the number of rows and columns gets quite large such that we have roughly 25.000 cells to render. This yields to the effect, that the rendering process for the component tree takes a lot of time: on my windows machine approx 7 seconds and, for some reason we have not found out about until now, on the integration machine (IBM server) around 45 seconds. Clearly, this is not acceptable. Now, my question is, how should we address this problem? Is the naive approach of using two nested ListViews and rendering each as component plain dumb? What would be the alternatives? Thanks for any help, J. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - 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 -- Dr. Jürgen Lind www.agentlab.de __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Large number components and redering time
please don't tell me that there is any person around that needs 25k elements per page... this is a fault in the specification of the former system also :) Am Mittwoch, 17. Februar 2010 19:30:29 schrieb d...@agentlab.de: Surely a change in the use case would ease our lives, unfortunately we are migrating a legacy application to a new technology and the look and feel (if you could call it that) must be retained... J, Josh Chappelle wrote: Could you use a PageableListView or does that not fall within your business requirements? Josh -Original Message- From: d...@agentlab.de [mailto:d...@agentlab.de] Sent: Wednesday, February 17, 2010 12:08 PM To: users@wicket.apache.org Subject: Large number components and redering time Hi, I have a question on how to address a certain problem that arose in my current project: we have a two-dimensional array with a variable number of rows and columns (not exactly rocket science, I know) that needs to be rendered in an HTML table where each cell is currently represented by a wicket-Label. Now, in the production environment, the number of rows and columns gets quite large such that we have roughly 25.000 cells to render. This yields to the effect, that the rendering process for the component tree takes a lot of time: on my windows machine approx 7 seconds and, for some reason we have not found out about until now, on the integration machine (IBM server) around 45 seconds. Clearly, this is not acceptable. Now, my question is, how should we address this problem? Is the naive approach of using two nested ListViews and rendering each as component plain dumb? What would be the alternatives? Thanks for any help, J. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - 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 -- binaere bauten gmbh · tempelhofer ufer 1a · 10961 berlin +49 · 171 · 9342 465 Handelsregister: HRB 115854 - Amtsgericht Charlottenburg Geschäftsführer: Dipl.-Inform. Ilja Pavkovic, Dipl.-Inform. Jost Becker - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Large number components and redering time
I set up a WicketTester Testcase and used Eclipse TPTP to look into the app. Over 90% were spent in beforeRender calls... However, since the load that was produced by running the testcase within a monitored environment brought my computer to its knees, I will have to dwell deeper into the problem using other tools than eclipse TPTP... J. Martin Makundi wrote: Hi! Did you jprofile where the time is spent? ** Martin 2010/2/17 d...@agentlab.de: Hi, I have a question on how to address a certain problem that arose in my current project: we have a two-dimensional array with a variable number of rows and columns (not exactly rocket science, I know) that needs to be rendered in an HTML table where each cell is currently represented by a wicket-Label. Now, in the production environment, the number of rows and columns gets quite large such that we have roughly 25.000 cells to render. This yields to the effect, that the rendering process for the component tree takes a lot of time: on my windows machine approx 7 seconds and, for some reason we have not found out about until now, on the integration machine (IBM server) around 45 seconds. Clearly, this is not acceptable. Now, my question is, how should we address this problem? Is the naive approach of using two nested ListViews and rendering each as component plain dumb? What would be the alternatives? Thanks for any help, J. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - 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 -- Dr. Jürgen Lind www.agentlab.de __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Large number components and redering time
How long does it take to pull up the static html in your browser? Just the browser render can be non-trivial for a large enough file. Are you using arrays instead of collections and (where possible) primatives instead of objects? An int[100,250] is much smaller than a comparably scaled ListListInteger. Scott On Wed, Feb 17, 2010 at 10:30 AM, d...@agentlab.de wrote: Surely a change in the use case would ease our lives, unfortunately we are migrating a legacy application to a new technology and the look and feel (if you could call it that) must be retained... J, Josh Chappelle wrote: Could you use a PageableListView or does that not fall within your business requirements? Josh -Original Message- From: d...@agentlab.de [mailto:d...@agentlab.de] Sent: Wednesday, February 17, 2010 12:08 PM To: users@wicket.apache.org Subject: Large number components and redering time Hi, I have a question on how to address a certain problem that arose in my current project: we have a two-dimensional array with a variable number of rows and columns (not exactly rocket science, I know) that needs to be rendered in an HTML table where each cell is currently represented by a wicket-Label. Now, in the production environment, the number of rows and columns gets quite large such that we have roughly 25.000 cells to render. This yields to the effect, that the rendering process for the component tree takes a lot of time: on my windows machine approx 7 seconds and, for some reason we have not found out about until now, on the integration machine (IBM server) around 45 seconds. Clearly, this is not acceptable. Now, my question is, how should we address this problem? Is the naive approach of using two nested ListViews and rendering each as component plain dumb? What would be the alternatives? Thanks for any help, J. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - 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 -- Dr. Jürgen Lind www.agentlab.de __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - 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
Re: Large number components and redering time
Granted, it is not very readable and we are investigating ways in re-defining the requirements. But as of now, the requirements stand as they are... and I have to find a way of meeting them... J. Ilja Pavkovic wrote: please don't tell me that there is any person around that needs 25k elements per page... this is a fault in the specification of the former system also :) Am Mittwoch, 17. Februar 2010 19:30:29 schrieb d...@agentlab.de: Surely a change in the use case would ease our lives, unfortunately we are migrating a legacy application to a new technology and the look and feel (if you could call it that) must be retained... J, Josh Chappelle wrote: Could you use a PageableListView or does that not fall within your business requirements? Josh -Original Message- From: d...@agentlab.de [mailto:d...@agentlab.de] Sent: Wednesday, February 17, 2010 12:08 PM To: users@wicket.apache.org Subject: Large number components and redering time Hi, I have a question on how to address a certain problem that arose in my current project: we have a two-dimensional array with a variable number of rows and columns (not exactly rocket science, I know) that needs to be rendered in an HTML table where each cell is currently represented by a wicket-Label. Now, in the production environment, the number of rows and columns gets quite large such that we have roughly 25.000 cells to render. This yields to the effect, that the rendering process for the component tree takes a lot of time: on my windows machine approx 7 seconds and, for some reason we have not found out about until now, on the integration machine (IBM server) around 45 seconds. Clearly, this is not acceptable. Now, my question is, how should we address this problem? Is the naive approach of using two nested ListViews and rendering each as component plain dumb? What would be the alternatives? Thanks for any help, J. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - 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 -- Dr. Jürgen Lind www.agentlab.de __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Large number components and redering time
The amount of data that is generated is aroung 1MB so the time to bring it to the browser is not the problem (in a LAN setting). Also, Firebug does not give me any sign of rendering problems in the browser. Also, the large amount of time is also consumed in a WicketTester set-up without network or browser... The datastructures are lists but measuring the time for pulling the data from the DB and building the component tree shows no signs of performance issues. The problem does not occur before the actual rendering within wicket... J. Scott Swank wrote: How long does it take to pull up the static html in your browser? Just the browser render can be non-trivial for a large enough file. Are you using arrays instead of collections and (where possible) primatives instead of objects? An int[100,250] is much smaller than a comparably scaled ListListInteger. Scott On Wed, Feb 17, 2010 at 10:30 AM, d...@agentlab.de wrote: Surely a change in the use case would ease our lives, unfortunately we are migrating a legacy application to a new technology and the look and feel (if you could call it that) must be retained... J, Josh Chappelle wrote: Could you use a PageableListView or does that not fall within your business requirements? Josh -Original Message- From: d...@agentlab.de [mailto:d...@agentlab.de] Sent: Wednesday, February 17, 2010 12:08 PM To: users@wicket.apache.org Subject: Large number components and redering time Hi, I have a question on how to address a certain problem that arose in my current project: we have a two-dimensional array with a variable number of rows and columns (not exactly rocket science, I know) that needs to be rendered in an HTML table where each cell is currently represented by a wicket-Label. Now, in the production environment, the number of rows and columns gets quite large such that we have roughly 25.000 cells to render. This yields to the effect, that the rendering process for the component tree takes a lot of time: on my windows machine approx 7 seconds and, for some reason we have not found out about until now, on the integration machine (IBM server) around 45 seconds. Clearly, this is not acceptable. Now, my question is, how should we address this problem? Is the naive approach of using two nested ListViews and rendering each as component plain dumb? What would be the alternatives? Thanks for any help, J. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - 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 -- Dr. Jürgen Lind www.agentlab.de __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - 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 -- Dr. Jürgen Lind www.agentlab.de __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Large number components and redering time
i would imagine you would have the same problem even in a local environment such as swing... the solution is quiet simple, instead of using wicket components to model the table and the cell simply use a single component that writes out html for the entire table. -igor On Wed, Feb 17, 2010 at 10:08 AM, d...@agentlab.de wrote: Hi, I have a question on how to address a certain problem that arose in my current project: we have a two-dimensional array with a variable number of rows and columns (not exactly rocket science, I know) that needs to be rendered in an HTML table where each cell is currently represented by a wicket-Label. Now, in the production environment, the number of rows and columns gets quite large such that we have roughly 25.000 cells to render. This yields to the effect, that the rendering process for the component tree takes a lot of time: on my windows machine approx 7 seconds and, for some reason we have not found out about until now, on the integration machine (IBM server) around 45 seconds. Clearly, this is not acceptable. Now, my question is, how should we address this problem? Is the naive approach of using two nested ListViews and rendering each as component plain dumb? What would be the alternatives? Thanks for any help, J. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - 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
Re: Large number components and redering time
And loadabledetachablemodels are in place? ** Martin 2010/2/17 d...@agentlab.de: The amount of data that is generated is aroung 1MB so the time to bring it to the browser is not the problem (in a LAN setting). Also, Firebug does not give me any sign of rendering problems in the browser. Also, the large amount of time is also consumed in a WicketTester set-up without network or browser... The datastructures are lists but measuring the time for pulling the data from the DB and building the component tree shows no signs of performance issues. The problem does not occur before the actual rendering within wicket... J. Scott Swank wrote: How long does it take to pull up the static html in your browser? Just the browser render can be non-trivial for a large enough file. Are you using arrays instead of collections and (where possible) primatives instead of objects? An int[100,250] is much smaller than a comparably scaled ListListInteger. Scott On Wed, Feb 17, 2010 at 10:30 AM, d...@agentlab.de wrote: Surely a change in the use case would ease our lives, unfortunately we are migrating a legacy application to a new technology and the look and feel (if you could call it that) must be retained... J, Josh Chappelle wrote: Could you use a PageableListView or does that not fall within your business requirements? Josh -Original Message- From: d...@agentlab.de [mailto:d...@agentlab.de] Sent: Wednesday, February 17, 2010 12:08 PM To: users@wicket.apache.org Subject: Large number components and redering time Hi, I have a question on how to address a certain problem that arose in my current project: we have a two-dimensional array with a variable number of rows and columns (not exactly rocket science, I know) that needs to be rendered in an HTML table where each cell is currently represented by a wicket-Label. Now, in the production environment, the number of rows and columns gets quite large such that we have roughly 25.000 cells to render. This yields to the effect, that the rendering process for the component tree takes a lot of time: on my windows machine approx 7 seconds and, for some reason we have not found out about until now, on the integration machine (IBM server) around 45 seconds. Clearly, this is not acceptable. Now, my question is, how should we address this problem? Is the naive approach of using two nested ListViews and rendering each as component plain dumb? What would be the alternatives? Thanks for any help, J. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - 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 -- Dr. Jürgen Lind www.agentlab.de __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - 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 -- Dr. Jürgen Lind www.agentlab.de __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - 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
Re: Large number components and redering time
We had some troubles like this in the past. It turned out that the Ajax links that were in the cells were troublesome, I believe. Search the archives. Someone gave me some code to fix it, but I don't have it handy right now (or I don't know how to find it if I do). On Wed, Feb 17, 2010 at 1:42 PM, d...@agentlab.de wrote: The amount of data that is generated is aroung 1MB so the time to bring it to the browser is not the problem (in a LAN setting). Also, Firebug does not give me any sign of rendering problems in the browser. Also, the large amount of time is also consumed in a WicketTester set-up without network or browser... The datastructures are lists but measuring the time for pulling the data from the DB and building the component tree shows no signs of performance issues. The problem does not occur before the actual rendering within wicket... J. Scott Swank wrote: How long does it take to pull up the static html in your browser? Just the browser render can be non-trivial for a large enough file. Are you using arrays instead of collections and (where possible) primatives instead of objects? An int[100,250] is much smaller than a comparably scaled ListListInteger. Scott On Wed, Feb 17, 2010 at 10:30 AM, d...@agentlab.de wrote: Surely a change in the use case would ease our lives, unfortunately we are migrating a legacy application to a new technology and the look and feel (if you could call it that) must be retained... J, Josh Chappelle wrote: Could you use a PageableListView or does that not fall within your business requirements? Josh -Original Message- From: d...@agentlab.de [mailto:d...@agentlab.de] Sent: Wednesday, February 17, 2010 12:08 PM To: users@wicket.apache.org Subject: Large number components and redering time Hi, I have a question on how to address a certain problem that arose in my current project: we have a two-dimensional array with a variable number of rows and columns (not exactly rocket science, I know) that needs to be rendered in an HTML table where each cell is currently represented by a wicket-Label. Now, in the production environment, the number of rows and columns gets quite large such that we have roughly 25.000 cells to render. This yields to the effect, that the rendering process for the component tree takes a lot of time: on my windows machine approx 7 seconds and, for some reason we have not found out about until now, on the integration machine (IBM server) around 45 seconds. Clearly, this is not acceptable. Now, my question is, how should we address this problem? Is the naive approach of using two nested ListViews and rendering each as component plain dumb? What would be the alternatives? Thanks for any help, J. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - 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 -- Dr. Jürgen Lind www.agentlab.de __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - 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 -- Dr. Jürgen Lind www.agentlab.de __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - 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
Re: Large number components and redering time
Swing uses a variety of TableCellRenderer on a per table instance basis. What component are you suggesting to use for this behavior in Wicket? Bernard On Wed, 17 Feb 2010 11:04:09 -0800, you wrote: i would imagine you would have the same problem even in a local environment such as swing... the solution is quiet simple, instead of using wicket components to model the table and the cell simply use a single component that writes out html for the entire table. -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Large number components and redering time
On Wed, Feb 17, 2010 at 1:31 PM, b...@actrix.gen.nz wrote: Swing uses a variety of TableCellRenderer on a per table instance basis. if you had a table cell that needed a button then you wouldnt use a renderer What component are you suggesting to use for this behavior in Wicket? a simple WebComponent that writes the table as an html string to the response. -igor Bernard On Wed, 17 Feb 2010 11:04:09 -0800, you wrote: i would imagine you would have the same problem even in a local environment such as swing... the solution is quiet simple, instead of using wicket components to model the table and the cell simply use a single component that writes out html for the entire table. -igor - 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
Re: Large number components and redering time
In case of repeated buttons I think I would use a combination of a TableCellEditor and a TableCellRenderer with a button behind them, still only single instances serving many rows. There would only be a single event listener that would check selected row index. Would it make sense to have that in Wicket in the future? Might save a lot of memory. If on the other hand this button would be only needed on specific cells, not the pure repeater scenario, then of course one would use simple button instances per cell as there would not be a significant memory saving. On Wed, 17 Feb 2010 13:37:01 -0800, you wrote: On Wed, Feb 17, 2010 at 1:31 PM, b...@actrix.gen.nz wrote: Swing uses a variety of TableCellRenderer on a per table instance basis. if you had a table cell that needed a button then you wouldnt use a renderer [snip] -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Large number components and redering time
we already provide support for all this...
class cheaprenderer implements ilinklistener {
protected void oncomponenttagbody(...) {
...
getresponse.write(href=\);
getresponsr.write(urlfor(this, ilinklistener.interface)+x=+x+y=+y));
}
public final void onclick() {
onclick(getrequest().getparameter(x), getrequest().getparameter(y));
}
protected abstract void onclick(int x, int y) ;
}
-igor
On Wed, Feb 17, 2010 at 4:03 PM, b...@actrix.gen.nz wrote:
In case of repeated buttons I think I would use a combination of a
TableCellEditor and a TableCellRenderer with a button behind them,
still only single instances serving many rows. There would only be a
single event listener that would check selected row index. Would it
make sense to have that in Wicket in the future? Might save a lot of
memory.
If on the other hand this button would be only needed on specific
cells, not the pure repeater scenario, then of course one would use
simple button instances per cell as there would not be a significant
memory saving.
On Wed, 17 Feb 2010 13:37:01 -0800, you wrote:
On Wed, Feb 17, 2010 at 1:31 PM, b...@actrix.gen.nz wrote:
Swing uses a variety of TableCellRenderer on a per table instance
basis.
if you had a table cell that needed a button then you wouldnt use a
renderer
[snip]
-igor
-
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
Re: Large number components and redering time
Many thanks. I like it. Good when memory is expensive :)
On Wed, 17 Feb 2010 16:21:16 -0800, you wrote:
we already provide support for all this...
class cheaprenderer implements ilinklistener {
protected void oncomponenttagbody(...) {
...
getresponse.write(href=\);
getresponsr.write(urlfor(this, ilinklistener.interface)+x=+x+y=+y));
}
public final void onclick() {
onclick(getrequest().getparameter(x), getrequest().getparameter(y));
}
protected abstract void onclick(int x, int y) ;
}
-igor
[snip]
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Large number components and redering time
Hi, Igor Vaynberg wrote: i would imagine you would have the same problem even in a local environment such as swing... absolutely, I was just wondering what would be the best way to do it in Wicket... the solution is quiet simple, instead of using wicket components to model the table and the cell simply use a single component that writes out html for the entire table. That's the solution a friend of mine suggested as well since he had similar problems in ZK. I was reluctant since writing out HTML felt somewhat un-wicket-ish. But I think that's the way to go for this kind of situation... Thanks everybody for your suggestions and comments. J. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
