PDA

View Full Version : v1.1b2-Bug in Combo?



itstarting
1 Jul 2007, 6:10 AM
My sample is very easy,just want to transform a SELECT to Combo,for example:

<select name="group.c_name" id="group.c_name">
<option value=""></option>
<option value="1">A</option>
<option value="2">B</option>
<option value="3">C</option>
</select>

so here is my code:



var combo;
Ext.onReady(function(){
combo = new Ext.form.ComboBox({
typeAhead: false,
triggerAction: 'all',
transform:'group.c_name',
width:300,
forceSelection:false,
resizable: true,
editable: true,
mode: 'local'
});
});


Then the problem is,if I type something like 'MM' and submit the form,the value is '' not 'MM',I think it's a bug mybe.

So I had to manual set the value before I submit, like this


function setComboValue(){
alert(combo.getValue());//it's ''
var o = document.getElementById('ext-gen9');
combo.setValue(o.value);
alert(combo.getValue());//it's 'MM'
}

AdamDawes
9 Jul 2007, 4:50 AM
I think I'm also experiencing the same problem.

When I set my combo up so that forceSelection is true, everything works normally and as expected. But when forceSelection is false, the value is only submitted if it's one that is picked from the list. Typing in a value that doesn't exist in the list always results in the last-selected value that does exist being submitted (even though the value I typed still appears within the field).

I can only assume that this is a bug, too. I will unfortunately have to limit my comboxes to only those that force selection for the time being.

(Edit: I've now tried this in the 1.0.1a release and the same thing happens there too).

davidd
10 Jul 2007, 12:40 AM
This might work, it worked for me.


var combo;
Ext.onReady(function(){
combo = new Ext.form.ComboBox({
typeAhead: false,
triggerAction: 'all',
transform:'group.c_name',
width:300,
forceSelection:false,
resizable: true,
editable: true,
hiddenName: 'group.c_name',
mode: 'local'
});
});

David...

AdamDawes
10 Jul 2007, 1:48 AM
Hi David,

Thanks for the suggestion -- unfortunately it doesn't seem to make any difference for me. I can see in Firebug my original field (changed to an ordinary input field with a type of "hidden") and the value updates in this whenever I select an item from the list. But typing in non-list items, it never updates, even with the hiddenName config option set.

I tried adding a function to the blur event which displayed the return value of the combo's getValue() function. This also only ever returns values from the list, typing a non-list value just results in the last-selected list value being returned.

However, if I modify my function to display the value of getRawValue(), this returns non-list items just fine. I can use this to provide a work-around by attaching a function with the following content to the 'blur' and 'specialkey' events of the combobox:


Ext.get('Combo1').dom.value = extCombo1.getRawValue();


I'm sure this isn't the intended behaviour, though.

I also noticed that the 'change' event doesn't seem to fire when leaving the field after changing the value (to a list or non-list item), hence my having to use the blur event instead.

mystix
10 Jul 2007, 3:22 AM
let's take a step back and observe the behaviour of a typical html <select> (i.e. dropdown) field:


you click on the <select> field
you're forced to make a selection from one of the existing <option>s, none of whose values (and display text) you may alter
if you fail to make a choice from one of the available <option>s, the default selected <option> is taken to be your choice, again propagating the idea of a "forced" selection
you click submit, and voila, your choice, forced or otherwise, is sent to the server


since we're transforming an existing <select> field into an Ext ComboBox, the ComboBox should behave the same way, with added advantages like:

you're now able to type in the field to make a selection (which should come from an existing list of options) instead of having to scroll through a (possibly) long list of options
it looks much better than a typical <select> :D


thus, imho, if you're doing something other than what a typical <select> does (like submitting text which doesn't exist in the <select> field's list of options) then you'll need to handle it separately.

i think the problem most of us have when dealing with ComboBoxes created from transformed <select>s is that they look like <select> fields, but they possess behaviours which are common to <input> fields also, so we expect them to allow us to make selections like a <select> field does AND revert to an <input> field's behaviour when we type text.

feel free to bonk me on the head if i'm not making any sense, or if you feel otherwise. ;)

AdamDawes
10 Jul 2007, 3:38 AM
Hi Mystix,

Thanks for the response -- you're certainly making sense, and far be it from me to bonk you on the head, I've only been using Ext for a couple of weeks and am very much still in newbie territory. :D

I certainly agree with all your reasons for using an Ext combobox instead of an HTML select field. However, the implication that I got from reading the docs was that if I pass forceSelection as false, I should be able to enter any text I like into the field. Which I can. All very nice and powerful (and in fact, one of the many things that really attracted us to Ext in the first place).

It was just a surprise to find that when I submit the form, the value displayed in the field wasn't the one submitted. If the expectation is for me to provide additional code to handle that, then that's fine, but I wasn't aware that I needed to.

Of course, this is indeed something other than what a typical select field can do, but that's why I'm using Ext, to do things that basic HTML isn't capable of doing. :)

Does the "fix" I posted in my previous message look reasonable? I don't want to implement something that breaks in a later version of Ext because I've approached it in entirely the wrong way.

Best regards,

bpjohnson
17 Jul 2007, 9:15 AM
The way I approached the same issue was this:


var options = { ... }; /* My options for the combo box. Fill in to suit. */
var forceSelection = options.forceSelection;
var comboBox = new Ext.form.ComboBox(options);
if (! forceSelection) {
comboBox.on('blur', function(){
/* value is the selection value if set, otherwise is the raw typed text */
var value = (this.getValue())?this.getValue():this.getRawValue();
this.hiddenField.value = value;
}, comboBox);
}

It may be more appropriate to use the 'changed' event, but I went for 'blur' because it was three letters shorter.

Cheers,
BrYan

itstarting
18 Jul 2007, 9:54 PM
var value = (this.getValue())?this.getValue():this.getRawValue();


It's not a good solusion because once you have select one Exactly option,the 'this.getValue()' will have a value,and then will not excute the script 'this.getRawValue();'

jratcliff
19 Jul 2007, 7:22 AM
I'm having the same issue as itstarting. The selected value of my transformed select is not being sent to the server.

The problem that I have is when your select is within a <font> tag (maybe it happens with other tags as well). DomHelper's insertHtml method then somehow appends the hidden input field into another font tag and thus the internal methods that set the value of the hidden input field are referencing the font element and not the input element.

Here's the html before the combobox is rendered:


<font face="Arial">
<input name="%%Surrogate_RequestType" type="hidden" value="1">
<select name="RequestType" id="RequestType">
<option value="Feature">Feature Request
<option value="Bug">Bug Report
</select>
</font>


And here's the html after the combobox has transformed the select


<font face="Arial" id="ext-gen116">
<input type="hidden" value="1" name="%%Surrogate_RequestType" id="ext-gen115" class="x-form-hidden x-form-field"/>
<div class="x-form-field-wrap" id="ext-gen122" style="width: 147px;">
<font>
<input type="hidden" id="RequestType" name="RequestType"/>
</font>
<input type="text" autocomplete="off" size="24" id="ext-gen121" class="x-form-text x-form-field"/>
<font id="ext-gen123">
<img class="x-form-trigger x-form-arrow-trigger" src="/extnd/extnd_1.0.0.nsf/extnd/resources/images/s.gif"/>
</font>
</div>
</font>


Notice how the hidden input field is WITHIN a font tag now.


<font>
<input type="hidden" id="RequestType" name="RequestType"/>
</font>


As a result the font element is what's returned as the reference since el.previousSibling points to font and not the input


<!-- snippet from DomHelper's insertHtml method -->
"beforebegin":
range.setStartBefore(el);
frag = range.createContextualFragment(html);
el.parentNode.insertBefore(frag, el);
return el.previousSibling;


When you step through Firebug the html string is correct (it's the hidden input) but the fraq variable that gets set from the range.createContextualFragment(html) call ends up being a font element with the hidden input being a child element.

So? Is this a bug that needs to be fixed in DomHelper? Since this markup is being generated by an IBM Lotus Domino server, I don't have control of telling it not to include the font tag.

bpjohnson
19 Jul 2007, 7:26 AM
var value = (this.getValue())?this.getValue():this.getRawValue();

It's not a good solusion because once you have select one Exactly option,the 'this.getValue()' will have a value,and then will not excute the script 'this.getRawValue();'


You're right. Hmm... I suppose the best way then would be to getRawValue(), which gets whatever text is in the field, and check the datastore to see if there's an associated value to go with it. If so, submit that, if not submit the text...

I'd whomp something up to test out, but I haven't had any coffee yet today and coding whilst uncaffeinated is a bad idea. ~o)

tryanDLS
19 Jul 2007, 7:39 AM
The better solution would be to get rid of the FONT tag :) It's a deprecated tag - styling of the element should be handled via CSS. Even if you use the FONT tag, I think it's semantically incorrect to put other HTML elements inside it - results are probably not consistent x-browser.

jratcliff
19 Jul 2007, 9:22 AM
The better solution would be to get rid of the FONT tag :) It's a deprecated tag - styling of the element should be handled via CSS. Even if you use the FONT tag, I think it's semantically incorrect to put other HTML elements inside it - results are probably not consistent x-browser.

Hi Tim,

I was afraid you might say that. However, with Domino, these tags are automatically generated by the server and there's no way for me to control this. Maybe in a future version of Domino they'll finally remove the hated FONT tag :) but until then I'll have to come up with a way around this. Also, since this is for the Ext.nd project, the solution I come up with will have to work for anyone using Ext.nd and Domino and therefore it will have to be solution that doesn't require the developer to have to do anything different within Domino Designer.

So...any ideas are welcome!

~JR

MarkDelp
21 Oct 2007, 8:52 AM
itstarting,
I am with you in assuming that Ext had this capability built-in. It seems like a common enough situation to have an editable combo box with a code value in the valueField and a display value in the displayField, and to also allow the user to type in a code value.
I see you posted you question on July 1, so you probably already solved it, but here is some code for people like me who are searching the forums.
~Mark



function GetValue(ctrl)
{
var value = ctrl.getValue();
var raw = ctrl.getRawValue();
var search = new RegExp('^' + raw + '$');
var found = ctrl.store.query(ctrl.displayField, search, false).getCount();
if (found == 0)
return raw;
else
return value;
}
}