You found a bug! We've classified it as
a bug in our system.
We encourage you to continue the discussion and to find an acceptable workaround while we work on a permanent fix.
Originally Posted by steffenk
The first Beta (not "Preview") release should include all components that will be in Ext 4.0. If anything is still missing at that point for any reason it will be made quite clear either in the release notes, blog post and/or compat file.
Ext JS Premium Member
IntelliJ IDEA has a great out of the box JS support regardless of the libraries you are using.
Ext JS Premium Member
What is the outlook for transforming SELECT elements to ComboBox controls via the transform: config? I notice that, in the PR5 source, there's a ComboBox that omits it, and a Combo-legacy that does not.
That certainly seems to me like it's very deprecated. If the "legacy" control is to be used in order to continue supporting transformed SELECTs, what impact will that have on overall compatibility in the app (what features will be missing, will it render correctly, etc.)?
Or, will it appear in the finished product (as I see that applyTo made its way back into Component)?
21 Mar 2011, 11:25 PM
Functionality for Element#child() and Element#down() has been swapped
-- child() now behaves as down(), and vice versa.
Has anyone any idea on when the migration documentation will be available?
The migration documentation and compatibility layer are being actively worked on and we're hoping to make them available soon. Not sure exactly when that will be just yet.
Ext JS Premium Member
Migration of Ext.form.ComboBox
OK, it's clear by this point that the transform config for a DOM element with Ext.form.ComboBox is not to be natively supported. I get that, and can use the renderTo config to build ComboBox controls outside of FormPanels (read: legacy HTML applications).
The problem for me is that there's a more fundamental change that's taken place - no longer is a hidden field created to allow both the display value and it's underlying value to be posted. Sure, I can create one myself, but then I have to keep it synchronized with the ComboBox.
It sure would be nice not to have to use "legacy" ComboBox code for this, and still have the ability to have two values post for a ComboBox.
What's the Sencha position on how to handle this situation, because there is definitely code out there that uses your controls but not your FormPanel and its submission logic?
IntelliSense for Ext 4.0?
Hi ... is there any information for integrating ExtJS 4.0 with Visual Web Developer (VWD) Express 2010 or VS 2010 in the way that JQuery is integrated?
Specifically I'm hoping to get robust and commented IntelliSense support for the full library as well as the subclasses that I make.
Any VWD users out there have any other success stories they'd like to share regarding ExtJS 4.0 integration?
You are correct, there is no longer a hidden field. In fact, one of the big goals for Ext4 forms was to totally decouple all Field components from input elements in the DOM. Many of the components still use a DOM input for display and gathering of user input, but its presence is not required for the field to function. The big advantage of this approach is that it allows fields to be populated, manipulated, and submitted without being rendered; this allows easier use in e.g. tab panels or collapsed fieldsets/panels/etc.
As a result, all submitting of Ext form fields is now programmatic; you can't dump an Ext field into a raw HTML form element and submit that form and expect it to work, because that form will depend on DOM inputs that may not be present. The best way is of course to use FormPanel and its associated Basic form implementation (though it's possible to write custom code that grabs submit values from fields), and we've made sure that these are powerful enough to handle most use cases, including creating and submitting a real form element in the background if that's what you need.
To your specific question: ComboBox's default behavior is to submit only a single value to the form; this value corresponds to the configured valueField if you're picking from the dropdown list. It doesn't seem like a common requirement to also submit the displayField as a second value; however if you wish to do so you could easily override the getSubmitData method to include that second value as well. You don't need to worry about creating a hidden input and syncing its value or anything. This is another advantage of the new architecture; since values are decoupled from DOM elements, it's usually easy to override a method or two and implement custom logic for handling the value(s).
I hope that helps.