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 [email protected]:
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: [email protected] [mailto:[email protected]]
Sent: Wednesday, February 17, 2010 12:08 PM
To: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
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: [email protected]
For additional commands, e-mail: [email protected]
