What if we used an wrapper for the array object and added an method like
commit() to the model. So we could change a lot of data in it and update its
visual representation at once (when calling commit()). That would give more
control over what the model and UI are doing and when it should be done.
Imagine a mass rename on 1200 items, it would be faster using the commit
approach.
That's more or less what the table widget is doing, because after you change
the model's data you have to fire an event telling the widget which rows
it suppose to update.
What do you think?
On Mon, Feb 21, 2011 at 7:34 AM, panyasan <[email protected]> wrote:
>
> Hi,
>
> Tobi has raised an important point. I use trees that have around 7000-10000
> nodes, so I guess modern javascript engines can handle these many
> qx.core.Object instances. And I really like the idea of the view reacting
> instantly on updates to the model. But of course, you will run into
> problems
> once the data becomes much bigger. I wonder if one could construct an
> architecture that works also with partially "rendered" raw data, i.e..
> native objects which get translated into qx.core.Object models only on
> demand.
>
> My experience with keeping huge trees on the server and rendering them on
> the client is that it is important to keep in mind how the data is
> structured (does the child node know what its parent node is or the other
> way round?) and that the node ids cannot be the same on the client and on
> the server since we do not know in what order the nodes on the client are
> being rendered (and the TreeVirtual was creating node ids sequentially).
>
> The same applies in some way on the client between the visual node
> representation, its model, and the "raw data" that is used to construct the
> model. Maybe the answer is already in the data architecture of qooxdoo. We
> have pluggable interfaces not only between the HTML representing the model
> and the qx.core.Object model (the internal "controller" of the virtual
> widgets), but also between the model and the data (the "marshaler"). That
> is, it would be the marshaller's job to make sure the model data is
> transformered sequentially into the live model, which in turn, will trigger
> updates to the visual state.
>
> Am I correct or do you see problems with this approach?
>
> C.
> --
> View this message in context:
> http://qooxdoo.678.n2.nabble.com/virtual-tree-and-lots-of-data-tp6040890p6048204.html
> Sent from the qooxdoo mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
