UPDATE 18/01/2009
Fixed regression where disabling the component didn't properly disable the items.
New version attached to the first post
Printable View
UPDATE 18/01/2009
Fixed regression where disabling the component didn't properly disable the items.
New version attached to the first post
I get this with 3.1.0 & desktop... With 3.0.0 everything is ok.
Code:this.el is undefined
this.el.dom.setAttribute('name', this.hiddenName || this.name);
We have the following use case: there is a form with field "Assigned user". Depending on some flag, it should allow for assignments of single user, or mulitple users. For multiple users assignment we use superboxselect; for single assignment we use a standard combo. However, it would be better to have it unified, and use superboxselect in both cases. But I don't see a setting for superbox to allow for selecting only one item. Do you have any plans of implementing such behavior in Superboxselect?
This has been asked before - I'll add your vote and put this functionality in a future version.Quote:
Originally Posted by grzegorz.borkowski
Thanks. Now when I think about it, it seems it would be better to have separate event for such a case added, e.g. "changeitem", because in single-select mode it makes no sense to fire removeitem-additem event pair at every change.
So in the multiple-select-mode you have additem and removeitem events; and in single-select mode you either have additem (when box is emtpy and first item is selected), changeitem (when another item is selected, replacing the previous one), and removeitem (when the single item is removed), OR in single-select-mode you have only changeitem: when box is empty and first item is selected you have this event fired with oldValue=null; when the item is removed, with newValue=null. Not sure at this moment which approach is better.
Yes, I understand your thinking, and when I get to implementing this, MAY make some changes to the events fired, OR if I think it adds too much complexity, I may just leave it to the developer to ignore the events that they aren't interested in - it would be easy enough for the end developer to check the mode in the callback and decide whether to act on the event or not. I'll see how it goes.Quote:
Originally Posted by grzegorz.borkowski
This could work, with one restriction: if, in case of item change in single-mode, the remove and add items are fired, I can write my program so that I ignore either remove or add events. Suppose I ignore remove events, and handle only add events, sending "change" message to the server then. The problem is what happens when user really removes item from combo box, without replacing it with new one: I will ignore this event, waiting for additem event, which will not happen.
It's still solvable if you handle the events differently - when an item is removed, send a message to the server, when an item is added, send another message. Just don't ignore the remove events. I don't think it's a huge overhead to send an additional event to the server. So on a replacement, you'd be responding to both the remove and the add.Quote:
Originally Posted by grzegorz.borkowski
Anyway, this is hypothetical at the moment as I haven't looked at how I'd implement this, but I'll bear in mind what you've said.
One more note, just to make sure we understand each other.
I'm thinking about such situation: you have a Task object with property "assignedPerson". It's modelled in DB as Task table with column ASSIGNED_USER_ID, so you can have only one assigned person. From model point of view, you can assign a person (set a field), change assigned person, and remove a person (clear the field). Assume also that we have a change log which displays any changes done to this object, based on, say, DB trigger. So if you change the assigned person in UI, and than look at change log, you expect there one record "assigned user changed from X to Y", not two records "user X removed", "user Y added". This one is perhaps not so serious case, but in some cases this distinction may be important. So if I sent two requests to server: "remove user X" and just after "add user Y", I can't expect the server will hang at first request and wait for another one to come, to send only one update to DB instead of two.
That's why I say that in this scenario it should be possible to distinguish the case of changing the item (from case on adding and removing) on the client side - and even on client side it will be not that easy I think if the SuperBoxComponent don't give you any clue what's going on.
I don't know if this is useful, but when I disable it, if it has no items selected it can still be retrieved with getValues() (returns "").
If it has values selected it can be disabled and nothing is retrieved.
Another thing - when I disable it and than enable it, there is no dropdown.
Other than that it's awesome. :)
Is there a way to force it to except only one value (kind of like a normal combo)?