On Wed, Mar 17, 2010 at 13:24, Dave Baggett <[email protected]> wrote:
>
>
> 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.
>
I had offered an alternate "solution" (which I didn't like much, but was
better than where this ended up) back while this was being debated. I
suggested adding disambiguating language to the method names, e.g.
getSelectionArray() which would make it obvious that it returned an array...
or at least cause someone to look up why it said "Array" there. I don't like
that naming scheme, but I felt that *something* had to be done to resolve
this issue that I expected to cause much confusion (and that has since come
up as a user issue a number of times), and I've been bitten by it a number
of times myself even though I know of the unified handling. I believe that
the unified handling is a very good concept in principle, but has problems
too great to leave as is.
In this case, even my method renaming scheme wouldn't have solved the
problem. Who would even consider that a TabView changing selection and
sending a "changeSelection" event would contain an array. (Maybe the event
name, too, should have "Array" appended to it, but that's even uglier.)
Short of switching back to a more "obvious" (in my mind) API, I think this
problem has to be solved with lots of documentation. As I was trying to help
solve Mathew's problem a couple days ago, I looked at the "changeSelection"
event declaration, the fireDataEvent() method call (which, unfortunately,
got its data from elsewhere so wasn't obvious that it was an array),
Widget.js where the low-level _indexOf() method being called was comiong
from, and a bunch of other places. If any of them had clearly stated, "This
method always returns an array even if only one element can be selected at a
time," I would have realized what was going on. The event, also, should be
documented this way.
Derrell
------------------------------------------------------------------------------
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
