Nick, Your points are all well taken. Consider the reason for this mess to be primarily historical. The Table widget dates back many, many years. It was (and remains) a wonderfully useful widget, which has proven to have its share of... shall we say... inconsistencies. With 20-20 hindsight, it's easy to find many things we'd do differently, and it has had numerous changes and additions as it has matured.
Some things, though, can't easily be changed. Most of the changes you are suggesting would not be backward-compatible, meaning all of the code that uses those widgets would have to change. The long-term goal is for Table to be obsoleted by a new member of the qx.ui.virtual.* family (not yet written). Although the new virtual table will likely come into existence within the next year, it will still be a number of years, probably, before qx.ui.table.* can be dropped completely from the framework in favor of the new widget, again for backward-compatibility reasons. The current Table widget is given love and attention to ensure that it continues to work properly and serve its function, but making significant changes to its API is probably inappropriate at this point. Cheers, Derrell On Thu, Feb 24, 2011 at 15:42, Nick Watkins <[email protected]> wrote: > > While working with the simple table model, it occurred to me how bizarre > the > getter methods on the model are: > > Why, when "getDataAsMapArray" always returns an array of maps and "getData" > always returns an array of arrays, does "getRowData" return either a map or > an array contingent on whether the "rememberMaps" argument is true when you > set table data? "getRowData" should ALWAYS return an array, just like > getData does, so I don't have to either remember my "rememberMaps" setting > or do some type checking. Weird. > > Why "getDataAsMapArray" instead of "getDataAsMap"? I understand that it > returns an array of maps, but if that reasoning is valid, then shouldn't > "getData" be called "getDataArrayArray"? If it were changed, it would align > so much easier to their row-level counterparts; it would merely mean the > inclusion of the word "Row" for the row-level methods. Weird. > > Why, after setting "rememberMaps" to true, can't I just set an argument to > any of the get methods to NOT return the metadata? One case I'm playing > with > now is having row data editable through a form inside a dialog. It's so > nice > to just call "this._dialog.getController().getModel().set(myTableDataObj);" > rather than having to strip out the metadata keys which don't correspond to > form fields. It might just be that my use case and how I'm handling the > translation of table rows to form model is kind of silly, I don't know. > Still, it would be nice to exclude metadata selectively. > > Obviously all this griping is easy to fix by some really simple code > additions to a model subclass, but I think the first two would probably be > good amendments to the framework proper. > -- > View this message in context: > http://qooxdoo.678.n2.nabble.com/Why-are-the-simple-table-model-s-row-data-getters-so-unnecessarily-weird-tp6061894p6061894.html > Sent from the qooxdoo mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT > data > generated by your applications, servers and devices whether physical, > virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >
------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
