Text Areas in Apex 4.2.2 - Can't be read dynamically - Bug?

Question

Hi,
i encountered a big problem after upgrading Apex from 4.1 to 4.2.2.
On an application page there is a Text Area which will be read and processed after clicking a button. I didn't want a refresh of the page and did it with a dynamic action.
All this worked like a charm with 4.1.
Since the upgrade, the value of the Text Area is always returned as null while processing the dynamic action, but the value is filled by the user!
When i change the type of the Element to Rich Text Area everything works fine, but i don't want this because i don't want HTML in the corresponding table.
Is this a bug? How can i workaround it?
Thank you
Regards
Daniel

Answer 1

Yep - it's a bug. But it only occurs when there is also a rich text editor present. The issue is in the initialization of an apex.item instance. When using jQuery .val() the value of the textarea can be retrieved, but not when using $v. And $v is a shortcut to apex.item.getValue. Since a dynamic action is an apex thing, it'll use apex.item.getValue to get the value. And that is returning nothing. The reason is not getValue being wrong, but an incorrect init of the apex.item object when the item concerns a textarea and there is a rich text editor present.
To explain this somewhat:
In getValue there is this code:
            if( !lArray ) {
                switch( _self.item_type ) {
                    /* check single checkbox entry */
                    case 'CHECKBOX'             :lReturn = ( _self.node.checked ) ? _self.node.value : ""; break;
                    /* check single radio entry */
                    case 'RADIO'                :lReturn = ( _self.node.checked ) ? _self.node.value : ""; break;
                    case 'TEXT'                 :lReturn = _self.node.value; break;
                    case 'POPUP_LOV'            :lReturn = _self.node.value; break;
                    case 'POPUP_KEY_LOV'        :lReturn = apex.jQuery( '#' + _self.node.id + "_HIDDENVALUE", apex.gPageContext$ ).val(); break;
                    case 'DATEPICKER'           :lReturn = _self.node.value; break;
                    case 'HIDDEN'               :lReturn = _self.node.value; break;
                    case 'DISPLAY_SAVES_STATE'  :lReturn = _self.node.value; break;
                    case 'DISPLAY_ONLY'         :lReturn = _self.node.innerHTML; break;
                    case 'TEXTAREA'             :lReturn = _self.node.value; break;
                    case 'FCKEDITOR'            :
                            oEditor = FCKeditorAPI.GetInstance( _self.node.id ) ;
                            lReturn = oEditor.GetHTML();
                            break;
                    default                     :lReturn = ""; break;
            return lReturn;
When textarea you'd expect a return of the value, but nope. Obviously when performing $v on the textarea nothing is returned so what occurs is the default clause.
Using
document.getElementById("P1_TEXTAREA").value
//or
$("#P1_TEXTAREA").val()
will return the value.
However, what is being tested is _self.item_type and _self.node.value.
These are properties instantiated when apex.item is called, as such
apex.item("P1_TEXTAREA")
Checking the console will show all the properties assigned. The node is correct, but item_type is empty... That explains the empty return from getValue.
So why is the item_type empty when there is a text editor?
item.js, line 147 (for those interested)
    if( lNodeType === 'FIELDSET' ) {
        //snipped out since irrelevant
    }else if( lNodeType === 'INPUT' ) {
        //snipped out since irrelevant
        // if the node type is not a fieldset or an input, initialise item_type accordingly
    } else {
        _self.item_type = lNodeType;
        switch( _self.item_type ) {
            case 'TEXTAREA':
                if( _self.node.parentNode.className === 'html_editor' && _self.node.parentNode.tagName === 'FIELDSET' ) {
                    _self.item_type = 'FCKEDITOR';
                } else {
                    try {
                        if (CKEDITOR.instances[ _self.id ] ) {
                            _self.item_type = 'CKEDITOR3';
                        } else {
                            _self.item_type = null;
                    } catch( e ) {}
                break;
            case 'SELECT':
                break;
            case 'SPAN':
                if( _self.node.className === 'display_only' ) {
                    _self.item_type = 'DISPLAY_ONLY';
                break;
            default:
                _self.item_type = false;
    } // end if on lNodeType
} //end if (_self.node)
The relevant parts here is the else clause on node type. You can see that firstly item_type is assigned the nodetype. In the case of a textarea the nodetype will be set to "TEXTAREA". Good.
Then, case TEXTAREA. First if? Nope, not an htmleditor. Else. Try. And in this try is the mistake. If there are no rich text editors then attempting to call CKEDITOR will throw an error since it will not be instantiated. That is good though, and makes sure that when there are no RTE's that the item_type will correctly be textarea since there is no re-assigment happening of item_type.
Consider now when there are RTE's. The CKEDITOR object will be instantiated, so no error. However, the textarea is obviously not in the array of editors since it is no editor, so it won't be found and we land in the else clause. There the item type is assigned "null". Thus, no longer "TEXTAREA".
So subsequently, when calling getValue the code will return nothing because of the "unknown" itemtype of the item.
So all that to say that yes, there is a bug in the apex code when you mix a textarea and a rich text editor on a page. Is there anything you can do to solve this? No, not really, save for editing item.js to account for the faulty assignment.
If you still have this requirement to have a textarea and RTE on the same page, then I can only advise you not to use a dynamic action, but using an ondemand process and calling it yourself, providing the correct value by using jQuery calls instead of apex ones.
(plus: should be logged as a bug by someone...)