it would be cool if we would know when all components are in, or just a page where missing components are mentioned (stroke through if they are implemented)
I would like to test with already existing app to see which issues arise. I already tested (with components should be in pr2) and the viewport isn't rendered at all, difficult to say why, as there is no js error at all.
Maybe it's worth to throw exceptions if a component / class is called that is not present, would make the debug much easier.
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.
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)?
Same as above ^^ Would like to begin migrating our application across from 3 to 4, but would prefer to do this gradually overtime with the help of the conversion file, then eventually will not need it anymore.
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?
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).