Derrell Lipman wrote: > > 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. >
I'm of two minds about this. On the one hand, this makes things much more complex and confusing for QooxDoo newcomers (and veterans, for that matter). On the other hand, code that manipulates QooxDoo widgets in a general way is much simpler when it can depend on a completely consistent selection interface. Think about data binding, for example -- it would be very ugly if that code had to special case a bunch of widgets because they offered one vs. the other selection API. On the other hand, it might be possible to have it both ways: let simple widgets offer the simple (non-array) selection API, let complex widgets off the complex one, and then make a property that can be queried to determine which one the widget offers. Dave -- View this message in context: http://n2.nabble.com/Determine-selected-TabView-page-tp4744540p4751747.html Sent from the qooxdoo mailing list archive at Nabble.com. ------------------------------------------------------------------------------ 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
