Hi Guilherme, Today Guilherme Aiolfi wrote:
> 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? The challenge I think, is in finding a way to provide a sensible interface which allows for both the current way of using a 'self aware' model as well as a simple data store. Since Martin has been the driving force behind the curent design (as far as I can tell) I guess he is in the best position to suggest a good pattern for solving this scaleability issue. 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
