Hi Martin, Today Martin Wittemann wrote: > > > Doesn't this sort of defeats the purpose of the virtual tree/list. > > > > Are there any thoughts on how to make this more dynamic ?
> The only change i can see is to allow plain javascript objects. > But again, with that, we would loos the change events and the > possibility to react on model changes. It would be great if the design was such, that the model was not inherently tied to the infrastructure that presents the data ... I guess you agree, that it is rather wasteful to have expensive infrastructure constructed (invisible model nodes) which is in all likelihood never going to be used ... At least in my experience I find that good performance for end-users is the big driver at the end of the day. I would like for the toolkit to make it simple for me to write code that furthers this ... with the new virtual widgets where the DOM impact is greatly reduced this goal is much closer, but tying things up with huge qx.object collections does not make sense to me ... as the traditional implementations did not have any issues with small data-sets anyway ... An alternate interface to provide data to the virtual widgets could solve this ... for small data-sets one could use the object model approach and for larger ones a data-only interface would be available. ... Ideally the model approach would be so generic that it could plug into the data-only interface and be used in other contexts as well. The way the qooxdoo table models work seem to hold quite some promise. I have not yet looked into the code, so I have no idea how this can be done on a practical level, but it is only code, so if there is a will, there is a way. cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch [email protected] ++41 62 775 9902 / sb: -9900 ------------------------------------------------------------------------------ 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
