Hi Jim, > For my app this is not feasible as I have no idea what the max number > of columns used would be, it's all user defined. I would logically > think that no more then 50 would be used but I recently saw an > instance that had over 100 columns. So I am not sure if it would be > practical to create all column models with something like 150 columns. > That might use up more memory then I am trying to save. > > I suppose I could pool everything but the tables, then hope that the > .8 version tables might lend themselves to pooling a little better.
I'm sorry but I have to dissapoint you in this regard :-( The table of 0.8 will be a port of the 0.7 table. We plan to rework many aspects of the table but only after 0.8. It would simply blow our release schedule. Maybe we could start collecting requirements to the "new" table. Being able to pool tables would be one of those requirements. Best Fabian -- Fabian Jakobs JavaScript Framework Developer 1&1 Internet AG Brauerstraße 48 76135 Karlsruhe Amtsgericht Montabaur HRB 6484 Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Oliver Mauss, Achim Weiss Aufsichtsratsvorsitzender: Michael Scheeren ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
