Best practice for org.ajax4jsf.xmlparser

[hanafey]

I have operated under the principle that in new applications with the Faclets view handler it is best to run with the xmlparser NONE because it is the most efficient. (I have also run into cases where the NEKO filter itself introduces a problem).

However, there can be problems when RichFaces components themselves break if the xml is not cleaned up by a filter. The most recent example is http://jira.jboss.com/jira/browse/RF-3577.

So the question is, what is best practice?
Should one strive to make everything work with xmlparser NONE?
Do the RichFaces develpers consider it a bug if a component by itself does not work under NONE?

[sergeysmirnov]

We always use NONE filter in our QA environment to test the components. The bugs are filed if problem occurs become of RichFaces code. Unfortunately, sometimes the problems happen because of the JSF implementations (JSF RI and MyFaces), like a bug with &# recoding in the response writer is several versions of JSF-RI. The similar one from the latest MyFaces (http://jira.jboss.com/jira/browse/RF-3557).
Only thing we can do is posting bug to their bug tracking system if it is not there yet. Avoiding such bugs is not always possible.

[sergeysmirnov]

"hanafey" wrote:
The most recent example is http://jira.jboss.com/jira/browse/RF-3577

We need the info about the environment. Otherwise, cannot reproduce.

[hanafey]

Thanks -- I see the problem has been fixed. Would never have guessed this would have had an interaction with scripts loading style.

Glad to hear you do QA under NONE.