> That was a hard problem to find (yet again!). The problem is that in the > process of solving one problem (multiple interfaces for dealing with > selections) a much greater problem was created. All selection functions > now return an ARRAY of selections, even when it is impossible for > multiple items to be returned. The problem is that e.getData() for the > "changeSelection" event returns a selection ARRAY. This is silly (nay, > ridiculous), and one of the few design decisions made by the core team > that I seriously disagree with... because it causes a complete waste of > time for all of us as we try to figure out why the obvious way to do > something doesn't work.
Although it is somewhat off-topic, I feel I should say something about the selections-always-return-an-array thing, maybe because I was one who supported this approach. The "obvious way" you refer to has usually to do with expectations - experiences gleaned from other frameworks, or earlier versions of qooxdoo. But repeating things doesn't improve them, it only avoids surprises (although I'm prepared to admit that the principle-of-least-surprise holds a value in itself). But the overarching goal we had was to *unify* selection handling throughout the framework. That means selections should work the same. Everywhere. On every occasion. If you would have worked with the selection API in one area of the framework, you would never have to learn something new, no matter which kinds of objects you are getting a selection from. A simple, unified API. One of the concessions to achieve this was to return list-valued results from *any* selection query. Which, if you think about it, is pretty much the behavior of other query APIs as well, e.g. SQL. Actually, of any query API I can think of. Which means you might only have to draw from a different set of experiences to come out at this point as the "obvious way" to do things :). It might also help to think about the alternatives. We already have the single-selection and multi-selection interfaces, but the multi-selection interface just adds a few additional methods to the single-selection interface, everything else is the same. Nice and easy. But to have 'getSelection()' return a scalar value in one and a list value in the other case, how would you do that? Have two methods 'getSelectionSingle()' and 'getSelectionMulti()'? What about widgets that support both kinds of selections, and make it customizable which one is in effect at a specific instance? How would they dynamically support either one or the other interface? How would the user know which interface to use? What would happen if he changed the customization during the life time of a particular object? T. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
