Hi everybody Thanks for the suggestion of Mike Kienenberger I open a discussion about this topic.
There is a problem with the behaviour of binding attribute from actionListeners, validators and converters. The jira issue of this topic is this: *MYFACES-1741<https://issues.apache.org/jira/browse/MYFACES-1741> * In resume, the spec doc says the following: "..... The implementation class for this action must meet the following requirements: * Must extend javax.faces.webapp.ConverterJspTag. * The createConverter() method must: If binding is non-null, call binding.getValue() to obtain a reference to the Converter instance. If there is no exception thrown, and binding.getValue() returned a non-null object that implements javax.faces.convert.Converter, register it by calling setConverter(). If there was an exception thrown, rethrow the exception as a JspException.Use the converterId attribute if the converter instance could not be created from the binding attribute. If the converterId attribute is set, call the createConverter() method of the Application instance for this application, passing converter id specified by their converterId attribute. If the binding attribute was also set, store the converter instance by calling binding.setValue(). Register the converter instance by calling setConverter(). If there was an exception thrown, rethrow the exception as a JspException. " Myfaces is doing what spec says but jsf ri don't. But jsf ri has the correct behaviour, which is instance the converters, validators and actionListeners "on demand", converters and validator on PROCESS_VALIDATION phase and actionListener before RENDER_RESPONSE (i suppose on INVOKE APPLICATION) phase. I have sent a email to jsf ri dev list about this, and this guys says this: > * Must extend javax.faces.webapp.ConverterJspTag. Ryan Lubke says: That's a bug - it should be ConverterELTag. But createConverter on ConverterELTag is abstract on the spec, so it's necessary to define this on a different way on org.apache.myfaces.taglib.core.ConverterTag > > The problem is that the actual JSF RI does not do what in spec says to > do, but JSF RI has a correct behaviour Ryan Lubke says: " I discussed this sometime back with the spec leads and the behavior in the RI is preferred. The spec should be updated (and probably will for 2.0). Before we made this change (I think it was before 1.2_03) we received several issues about the behavior of the binding attribute being non-intuitive prompted the change. " I have probed a custom converter with this strategy and works well, doing a new ComponentTag that extends from ComponentELTag that does something like this protected Converter createConverter() throws JspException { return new _DelegateConverter(_converterId,_binding,_converterIdString); } but this suppose some changes on several myfaces converter and validators components that has the binding attribute or use the actual createConverter() from ComponentTag. ConvertNumberTag has it's own way to save and restore the state (doing the same of _DelegateConverter plus save some attributes), but ConvertDateTimeTag does not save its state(but has a binding attribute, so i think it's necessary to correct his impl as ConvertNumberTag does) What is better? change the actual implementation of createConverter() on ComponentTag and do some corrections on child classes? or create a different ComponentTag class?. Suggestions and critics are welcome regards Leonardo Uribe
