0

According to this answer multiple converters on single value are not supported. So I tried to build chained converter by employing bean helper:

// Bean.java
public Converter chained(Converter... converters) {  return ...; } 

// view.xhtml
<p:inputText ... converter=#{bean.chained(aConverter, bConverter)} />

Unfortunatelly, this is not possible due of EL cast exception (proxy can not be cast to Converter nor to Object). This is probably caused by SpringBeanFacesELResolver registered in faces-config.xml.

Second attempt was try to build @FacesConverter from component attributes, however UIComponent#getAttributes() does not contain attributes where value is @Component injection.

<f:attribute name="converter_a" value="#{aConverter}" />

So the only way I can think of is to provide in attribute converter id and try to find it in "ChainingConverter" instance somehow.

Do you know how to find converter by id?

UPDATE

I've also tried to pass converter method as MethodExpression:

// Bean.java
public Converter chained(MethodExpression... expressions) {  return ...; } 

// view.xhtml
<p:inputText ... converter=#{bean.chained(aConverter.getAsString, bConverter.getAsString)} />

In this case {ConverterClass} does not have the property 'getAsString' (It seems that passing an expressions is possible only in composites with method-signature attributes).

UPDATE

I have ended with solution which builds converter in backing bean:

// Bean.java
public Converter getConverter() { return ...; }

// view.xthml
<p:inputText ... converter=#{bean.converter} />
matoni
  • 2,479
  • 21
  • 39
  • Why do you need this? I've never had this requirement myself the recent years, nor seen it being asked before. – Kukeltje May 12 '19 at 16:54
  • @Kukeltje It would be useful to compose converter from the existing ones e.g. String might be processed by multiple converters. – matoni May 12 '19 at 17:06
  • Same question... Why multiple converters after one another? – Kukeltje May 12 '19 at 17:33
  • @Kukeltje I know I can write specific converter which will do what I want, but such a design is poor. Suppose you have input where you need to apply only "trim" conversion, another might require to apply "trim" + "encoding" conversion, etc. Why to write multiple converters each for specific case, when composition would solve all the cases? – matoni May 12 '19 at 17:36
  • I never told you to write a single converter, I wanted to know why you think you need multiple converters Are you sure trimming, encoding is not better executed in the model or business layer instead of the view? – Kukeltje May 12 '19 at 18:52
  • @Kukeltje I was trying avoid to processing an input in model/business layer. I've ended with converter creation/composition in backing bean. – matoni May 12 '19 at 20:21
  • You don't 'process an input' in a business/model layer, you process a business value in the business/model layer. If you think you did the former, maybe your model got replicated in the controllers: https://stackoverflow.com/questions/10301363/jpa-entity-as-jsf-bean – Kukeltje May 13 '19 at 06:44
  • I guess you misinterpreted the error. EL does **not** support varargs in first place. Just create a method with two arguments. – BalusC May 13 '19 at 11:27

0 Answers0