Hi,
AFAIK the solutions for large numbers of cells in GUI frameworks are:
1) Do not render cells that are not in the scrollable view
2) Create components only per once row or column and provide cell
renderers. See javax.swing.table.TableCellRenderer
With these approaches there is basically no limit to the amount of
data that can be displayed on the screen.
The current architecture seems to be here that the entire view is
"rendered" on the server irrespective of how much of it is displayed
in the client. This rules out 1)
Still the current architecture allows to exploit 2) which would solve
your performance problem if applicable to your use case. But that is
theory until someone creates TableCellRenderer for Wicket.
Kind Regards,
Bernard
On Tue, 26 Mar 2013 16:07:17 +0100, you wrote:
>Hi,
>
>Lets say I have about ~100.000 of MarkupContainer objects that I want to put
>into a ListView or RepeatingView.
>This works fine functional wise... It's rather slow though.
>
>It boils down to:
>MarkupContainer:
>1309 private Component put(final Component child)
>1310 {
>1311 int index = children_indexOf(child);
>1312 if (index == -1)
>1313 {
>1314 children_add(child);
>1315 return null;
>1316 }
>1317 else
>1318 {
>1319 return children_set(index, child);
>1320 }
>1321 }
>
>and the call to "children_indexOf(child)" where it loops over all it's
>existing children and compares the id's until a match is found.
>With an increasing amount of children this can get rather slow...
>
>I though off overruling some functionality in the MarkupContainer class since
>I'm sure that for this list of items the children will be unique in their id
>and don't need that lookup, and overruling the "put" or "children_indexOf"
>function would give me enough power to skip that performance impacting part.
>But most functions have private access, leaving me nothing to control the
>adding of child components to a MarkupContainer.
>
>Does anyone else have experience with adding rather large quantities to
>something like the ListView and/or RepeatingView?
>Or is there another way of rendering this large amount of containers?
>
>Thanks in advance.
>
>Kind regards,
>Marco
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
