[beta] Ext.ux.ItemSelector (part of Ext.ux.Multiselect v1.2)

[J.C. Bize]

-1 to forcing single-selection for keyboard nav, at least left/right arrows.

Sorry for being unclear... I did not mean forcing single selection, even for keyboard navigation. I think we are all in agreement that multiple selection is a must for this control.

In order to implement keyboard navigation correctly however, the user needs to know where the selection focus lies within the control when looking at it. Currently, items can be highlighted simultaneously in both the source and destination lists:

multiselect_unclearfocus.jpg

When looking at the control in this state, users would not know where the focus currently lies; they would be left guessing what would happen when hitting one of the arrow keys.

I proposing that only the list that currently has focus displays its items as highlighted. This would resolve at least *some* ambiguities with keyboard navigation.

Ideally a new, separate selection focus rectangle should be implemented for proper keyboard navigation, but I am not sure how much additional work that would require.

multiselect_focusrect.jpg

Cheers,
JC

[JeffHowden]

Sorry for being unclear... I did not mean forcing single selection, even for keyboard navigation. I think we are all in agreement that multiple selection is a must for this control.

In order to implement keyboard navigation correctly however, the user needs to know where the selection focus lies within the control when looking at it. Currently, items can be highlighted simultaneously in both the source and destination lists:

Attachment 1498

When looking at the control in this state, users would not know where the focus currently lies; they would be left guessing what would happen when hitting one of the arrow keys.

Well, I can see how it might be ambiguous with ranking, though it could be understood that the ranking would get applied to any items that are selected. However, with moving items from one list to another I think it's much less ambiguous. After all, you can only move items from the left to the right with the right arrow button and vice versa.

[galdaka]

My suggestions:

1) When an item or items are moved from the source panel to the destination panel, the dragged layer must be contain a graphical represention or number (and text) eof dragged items. (See image1 and image2). Posibilty to insert items in specific positions.

2) Instead of using images for the buttons as a whole, instead they should use icons and be Ext buttons. Enable/disable arrows buttons based on selection (or lack of it).

3) More buttons: "Add all" and "Remove all".

Good work! and thanks in advance,

[tjstuart]

Shouldn't we agree on a single definition of a DraggableView/DDView so that the Ext.ux package is self consistent?

Yes I agree. Happy to use yours. Only drawback I see is dependencies for the end user ie. anyone that wants to use ItemSelector has to download DDView...on second thoughts maybe that's not a big deal as long as it is made clear.

One thing I noticed that was a "bug" in my Ext.ux.DDView, and still shows, is selection order.

If you click the bottom element, shift click the top element, and then drag them over, the order will reverse. Selection order becomes the actual element order.

I'm planning (public holiday here today) to change getSelectedItems to loop through the Store in its natural order, calling isSelected on each Record, and push it onto the Array if it is selected. That will keep the order the same.

Have this problem also so hopefully DDView deals with it eventually

[Animal]

I'll do that today.

[jack.slocum]

One thing I noticed that was a "bug" in my Ext.ux.DDView, and still shows, is selection order.

If you click the bottom element, shift click the top element, and then drag them over, the order will reverse. Selection order becomes the actual element order.

Animal, I don't think that is a bug. I think that is the correct behavior. It allows for you to reorder, without having to reorder. What I mean is, the order in which you select the items is the order in which they are dropped.

Please don't remove that "feature" as I think it has quite a few valid use cases and many users might like it (like me ).

[Animal]

OK, perhaps I can make it an option.

Most of the time, I want the visual order to be mantained. If I click on the bottom element first, and shift-click on the top, and then drag, I don't want my Components in the Menu in reverse order of what I see.

I can see the utility in being able to actually select in order and have the elements drop in that order.

I will update my DDView class today with an option to preserveSelectOrder with default false.

[falcondot]

Hi ,

this MultiSelect n ItemSelector are not working on opera 9.01

this error is coming when I try to run your demo example url on opera 9.01 .....

[falcondot]

In opera there is one more error coming ....

on line number 377 in your MultiSelect.js ...inside ItemSelector onRender function you have this code

  
		var tr = table.createChild({tag: 'tr'});
		tr = tr.child('tr'); // Line above auto creates <tbody> tag???
		var td = Ext.get(tr.dom.appendChild(document.createElement('td')));

but the line "var tr = table.createChild({tag: 'tr'});" is not creating a tbody by default as it does in IE n Firefox so when we do "tr = tr.child('tr'); " . it gives an error ...cannot convert from undefined to null to an object .....

[tjstuart]

@falcondot

Expect a new release this week which will address the issues you raised (together with some enhancements etc that others have requested)

@Animal

Will attempt to use your DDView. You anticipate much effort incorporating it into my ItemSelector as I havent yet really looked at DDView.