Actually, the performance problem was in the first row, well actually the
header that
was rendering all days in a week/month/year.
Each data row itself has a lot less items.
Each row has items that are absolutely positioned within the relatively
positioned row.
Each item can span over multiple days/week/months or even years, depending on
the
task duration.
Doing this instead of rendering divs for each day saves a lot of calculation on
the
server side and a whole lot less html on the client side.
And this creates other nifty possibilities like making the item divs resizable
and
draggable in that row with bound ajax calls to those actions.
For showing a grid I've done some background images that match the zoom level,
since each day is static in width.
I've thought about lazy loading the rows that where outside of the scrollable
view,
since I indeed have a scrollable view.
But that's something for the future.
Rendering the 287 years, e.g. 104k~ ish days, did render eventually and the
server
and browser didn't choke, but the div with was about 5M px width wide, so that
was
nonsense :P
On Wednesday 27 March 2013 05:25:40 Bernard wrote:
> 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]
