[UPDATED WORKAROUND] SEVERE unicode/ UTF-8 ADFm bidnig/invokation problem

Question

I have BIG problem with very simple search page use-case (with one text input field, search button and af:table for results). It looks like the unicode input value is somehow ruined during PPR and model update cycle (the unicode value is internally collated to ascii while transferred to EJB method)!!!
Here is the scenario (please note that all was created by pure drag-and-drop from Data Controls palette):
I have one inputText field on page, value of which is bound to simple attribute binding (say #{bindings.key.inputValue}) which is bound to vKey variable.
In PageDef I have methodIterator with
<methodIterator Binds="XYZ.result" Refresh="always" ...(the XYZ is method in some EJB) and I have adequate methodAction XYZ defined with named param:
<NamedData NDName="key" NDValue="${bindings.vKey}" NDType="java.lang.String"/>The table is bound to tree binding bound to the above methodIterator. The button is PPR trigger for table (only thing nod done by drag-and-drop).
JSPX page is xml encoding="UTF-8" with:
<jsp:directive.page contentType="text/html;charset=UTF-8"
                       pageEncoding="UTF-8"/>There are no locale settings in faces-config.xml (the default config).
In inputText I entered some unicode input text like "ЧШЩЪ".
When button is clicked, the methodAction XYZ is invoked.
The debugger brake-point is set inside EJB method.
Now, during the PPR after button click, the EJB method brake-point is hited twice (I assume because the Refresh="always" for methodIterator). In firs hit, the value of key parameter is OK (correct unicode value visible in Inspect...). BUT, the second time (during the same PPR) the method is invoked WITH totally ruined value of "????"! Of course, the search didn't find anything...
Thus, not only that problem of unicode is related to localization of pages/resources but something strange is happening with value binding also.
Can someone help?
Message was edited by:
PaKo
Message was edited by:
PaKo

Answer 1

Another way around:
Instead using processScope or pageFlowScope (which is not releasing memory automatically so it may make you a problems further on), I discovered an alternative workaround:
instead binding to #{bindings.someAttribBinding.inputValue} (which suffers from UTF-8 bug as concluded), you can bind your text inputs directly to #{bindings.someIterator.currentRow.dataProvider. someAttribute } which binds directly to your underlying data source property.
In my case, I use EJBs so the underlying datasource is Entity bean and this way I bind directly to setter method thus overriding any ADFm interference.
This shows to be more reliable and also MORE EFFICIENT! In case of indirect (via buggy attribute) binding, the getter method in entity is called twice while in case of direct binding (through .currentRow.dataProvider.someAttribute) the getter is called only once per page lifecycle (the setter is called once in both cases).
I would, thus, suggest to ADF team to consider introduction of some sort of better support for direct binding to the underlying data sources instead through Iterators and Attribute bindings. On example, introduce Entity Binding (like Tree binding, but with direct support for access to entity attributes including parent/children collections). This also apply for list bindings where it is NECESSARY to enable object binding from list to entity attribute (as EJB entities don't know for foreign keys but for related entities so the attribute mapping supported with current list bindings is totally useless).
Regards,
Pavle