Feature request - output-model populate with desired properties about angular-multi-select HOT 4 CLOSED

Hi @lepipele ,

Actually yes, the next release will have something similar to that. I'll be moving toward the more traditional "label & value" concept of HTML's select-options element (well at the moment we already have the labels, but I use the boolean tick-property instead of a list of values).

I am currently considering some options such as:

1. output-list: something like you mentioned earlier - this is also logical given that most of us store multiple selection in a, say, comma separated list, in our database.
2. We'll also have preselected-list and/or maybe preselected-model
3. In determining which items are preselected; most likely the tick-property will stay, but the new preselected-list and/or preselected-model will have higher priority.

I assume that these changes are rather necessary for the AJAX-based input loading.

This is also the reason why at the moment I'm a bit restrictive in accepting pull requests. Working on the core logic of the directive, I'm afraid there will be quite some things affected here and there.

Btw since version 2.0.0, you no longer need to specify class="multiSelect" in your input model's HTML code.

Thanks for the kind words, glad the directive works for you! Do help me to spread it to those who might need it.

from angular-multi-select.

@isteven

Well, if you are on it, I guess I'll just hang on and see how it turns out.

For separating preselected-list and output-list - I really believe in databinding model - UI controls are just what allows common user to tweak the data behind that's then used in algorithms.

In that sense, as long as they can bind to same value, I'm OK with that. Although I think the better approach would be to have something like databind-list & output-list - where databind-list is the one that gets pre-selected and modified as user changes selection. Output-list would be just extra option in case developer wants to output list of selected items for something else.

I think that in 99% of cases developers are working with unique IDs in select elements (if you are not then you would probably benefit from changing your database structure and have unique id as simple primary key instead of complex key with multiple fields... if you really want complex keys you can always go with generating unique key by doing: field1-field2 ... etc)... and because of that they would really benefit from databinding.

Anyways, thanks again for the great component and I look forward to seeing how it'll be improved. As for spreading the word - of course - everyone should have UI component like this in their arsenal ;)

from angular-multi-select.

I actually disagree with @lepipele on "developers are working with IDs". For a very simple app - maybe it is sufficient, but anything more involved with any hint of a business logic or domain entites having just IDs is very detrimental. Also, generating keys via "field1-field2" is a horrible hack which I would very strongly argue against.

from angular-multi-select.

...

from angular-multi-select.