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
