Listbox (multi-select) and item order: is this a bug or not?

I learned something interesting today about how multi-select listbox TVs behave. They store the multiple values in the order that you select them (I knew that part already). BUT - when you go to edit a resource that has an existing list of values in a TV of this type, they will not be rendered in the order they were stored in - they will be rendered according to the alphabetical sort order rules that dictate how the TV's master list of values are displayed.

What this means, in practical terms, is that if the order of selected items in a multi-select TV is important to you, you will need to manually re-order the items before each time you save the resource - otherwise they will be re-ordered alphabetically.

Example:

My multi-select TV has the following list of options to choose from:

• aardvark
• bird
• cat
• dog
• elephant
• ferret

If I edit a resource for the first time, and select 'elephant', 'cat', and 'bird' (in that order), the value in the database will look like:

elephant||cat||bird

But: the next time I go to edit this resource, the "selected" items in the TV will not appear according to the order they are stored, but rather according to their position in the (alphabetized) master list. So they will show up in the form as:

• bird
• cat
• elephant

So what happens is that when I save the resource (unless I go to the TV tab and manually re-sort the items before saving), the same 3 values are saved in the database, but the field value now looks like:

bird||cat||elephant

This may or may not be problematic depending on what you are trying to do. In my case, I was using a multi-select TV to select multiple content widgets that need to appear in a certain order, or css/js files that need to be loaded one-before-the-other, etc.

So: Is it realistic to expect that MODX should not change the way your data is stored in the database unless you explicitly change it in the editing form? If so, this is a bug that should be fixed.

Or, is the order of items in a multi-select list not something that one should expect to, or depend on, having control over? In that case, I have had an unreasonable expectation of this TV type and need to adjust my plans accordingly. And it isn't a bug, just a quirk that shouldn't hurt you unless you are abusing the TV type.

I'm suspecting the former: that this is a bug. I think the expectation "If I don't edit a particular TV, MODX shouldn't change the stored value when I save a resource" is a reasonable one.

What do you think?

I'm pulling this opinion out of my butt, but I think it's logical that the items would be displayed in the order set in the TV itself, regardless of the order the user selects them in.

I'm not clear on whether you're saying that's always the case or not.

When you create the TV, are the fields alphabetized before saving, or is your order used?

I do think that the fields a user selects should be stored in the order that they will be displayed, rather than in the order the user selects them. I guess I would call that a feature request.

Quote from: BobRay at Jun 10, 2013, 05:35 PM

I'm pulling this opinion out of my butt, but I think it's logical that the items would be displayed in the order set in the TV itself, regardless of the order the user selects them in.

I'm not clear on whether you're saying that's always the case or not.

When you create the TV, are the fields alphabetized before saving, or is your order used?

The items are displayed (in the tv input list) in whatever order the snippet that generates the list returns them in.

As you select items, they appear as individual bubbles within the input field - in the order you selected them.


When you save the resource, they are stored in the database in that same order that you selected them.

(So, if you are displaying them in a page using the order they are in in the stored delimited string, you will be displaying them in the order you saved them in.

However, the next time you open the resource to edit, when the TV prepopulates in the form, the order will get switched back to the "list" order (whatever order the snippet that generates the list returns them in).

So if you aren't paying attention to that particular TV when editing the resource, the order of the items will be saved differently when you save. And then the list will display differently in the web page.

Quote from: BobRay at Jun 10, 2013, 05:35 PM

I do think that the fields a user selects should be stored in the order that they will be displayed, rather than in the order the user selects them. I guess I would call that a feature request.

I think the way to put it is that they are *displayed* (in the end resource) in the order that they are *stored*. But that order is subject to inadvertent change due to the way the manager form loads the selected values.

I think one of two things needs to happen to eliminate this quirky behavior:

1. The manager form should load the selected values in the order they were stored in the database (or)
2. Whilst selecting multiple items in the manager form, the "bubbles" should automatically sort into "list order", rather than "selected" order, so as to not give the false impression that the order of selection will affect the order the items are going to be stored in. (Which, remember, it *does* affect, but not in an ongoing reliable way).

I'd prefer option #1, because when selecting multiple items from a master list to form a subset list, I think order often matters to people. However, if we want to decide that it is a "business rule" of multi-select TVs that selected values will always be stored in the same order they appeared in the master list, then #2 is the way to go.

I think one of these 2 things has got to happen, because as it is now, the behavior is very erotic and quirky. I've had a pesky high-maintenance user call me multiple times telling me that the order of the widget-boxes on her home page keeps changing, and now that I've finally figured out why, I have to come up with a workable solution.

It's actually in the tracker in several tickets =)... http://tracker.modx.com/issues/9206 as this behavior has made the listbox unusable in several cases I'm using checkbox Sortables as an alternative http://modx.com/extras/package/checkboxsortable

this is a superbox-select-issue and how it is working. When filling the values it is just a option-list with selected/not selected options.
So not that easy to solve.

you may try the checkbox-sortable-grid for sortable options or use a checkbox-group or a simple listbox-multiple for not sortable options.

I was wondering whether this might be an extJS issue that was not simple to solve.

I'll have to check out the checkbox sortable option. I had been thinking of using MIGX, since that was the only sortable TV input I was aware of. But it would maybe be overkill for the things I need to do.

. . . as it is now, the behavior is very erotic and quirky

.

Maybe it's just me, but I don't find it all that erotic.

Quote from: BobRay at Jun 14, 2013, 12:55 AM

. . . as it is now, the behavior is very erotic and quirky

.

Maybe it's just me, but I don't find it all that erotic.

HA! Best typo and response ever.

I believe the word I was looking for was "erratic". Perhaps this was some sort of slip of the subconscious.

Quote from: jrotering at Jun 13, 2013, 12:05 PM

I was wondering whether this might be an extJS issue that was not simple to solve.

I'll have to check out the checkbox sortable option. I had been thinking of using MIGX, since that was the only sortable TV input I was aware of. But it would maybe be overkill for the things I need to do.

Exactly my scenario when finding checkbox sortable =)

from now on (version 2.5.2) its possible to fill the MIGX-TV with input-option-values.
Example usage see: http://rtfm.modx.com/display/ADDON/MIGX.sortable+resourcelist