Based on the suggestions of Gerhard, I completed the example and placed it here [1]
[1] https://sandbox890.googlecode.com/svn/trunk/examples/conversionException_extval Regards, Rudy De Busscher 2010/1/5 Gerhard Petracek <[email protected]> > hi rudy, > > you analyzed it correctly. it isn't the original task of extval but extval > definitely is able to help you. > > to solve your problem you have to implement your own RendererProxy and > register it. > > details/example: > you have to create an extval startup-listener and register your proxy. > since it's an internal concept and very deep in the core, there is no > specialized api for registering such proxies. > instead of a special api you have to use: > > ExtValContext.getContext().addGlobalProperty(ExtValRendererProxy.KEY, > CustomRendererProxy.class.getName()); > > afterwards you have to extend the original proxy implementation and > override the method getConvertedValue: > > public class CustomRendererProxy extends ExtValRendererProxy > { > public CustomRendererProxy(Renderer renderer) > { > super(renderer); > } > > @Override > > public Object getConvertedValue(FacesContext facesContext, UIComponent > uiComponent, Object o) throws ConverterException > { > try > { > return super.getConvertedValue(facesContext, uiComponent, o); > } > catch (ConverterException e) > { > throw convertException(e); > } > } > > private ConverterException convertException(ConverterException e) > { > //custom logic - in your case you have to replace the > placeholder... > return e; > } > } > > so you can do the same as shown in the example also with converter > exceptions. > > @interceptors (esp. ValidationExceptionInterceptor): > i'm sure you saw that the interceptors you mentioned are >validation< > exception interceptors (and the current milestone provides normal validation > interceptors as well). so it wouldn't be correct to call them in case of a > converter exception. however, if you really like to re-use the existing > interceptors, you can have a look at the implementation of > ExtValUtils#executeAfterThrowingInterceptors. ExtValUtils is marked as > internal - so it might be better to use the same (simple) implementation > instead of directly calling it. > > fyi: > validatorExceptionSource isn't used by internal interceptors and for the > metaDataEntry parameter it should be enough to create an empty instance. at > least the interceptors of the current milestone check if it is an entry > which can be processed by the current interceptor. > > anyway, if you do that you mix up different jsf concepts... > > regards, > gerhard > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > 2010/1/4 Rudy De Busscher <[email protected]> > > Trying ExtVal with JSF 1.1, I came across following 'issue'. >> >> I was playing with the OutputLabel example (see >> http://os890.googlecode.com/svn/trunk/java/web/jsf/extval/examples/advanced/demo_107) >> to see how the 'lack' of label attribute in JSF 1.1 can be solved by the >> ExtVal code. >> It works very good but then I came across the problem of a conversion >> validation problem. What I mean is the following thing: When we have a >> field bound to a 'numeric' property (like Integer) the conversion fails and >> isn't catched by the ExtVal code. >> >> The conversion problem results in a message where the field Id is >> displayed in the message, and not the label which is in front of it. >> >> I traced where the Exception passes through the ExtVal code and found the >> ExtValRendererProxy where the Conversion Exception is catched but not >> handled. >> See >> >> public Object getConvertedValue(FacesContext facesContext, >>> UIComponent uiComponent, Object o) throws ConverterException >>> { >>> ... >>> try { >>> >>> entry.setConvertedValue(wrapped.getConvertedValue(facesContext, >>> uiComponent, o)); >>> } catch ... >>> >> >> where the getConvertedValue is called from the 'original' renderer. The >> ExtVal code isn't dealing with the conversion 'problem' but just does a >> 'reset component proxy mapping'. >> >> The conversion isn't really the main core of the ExtVal code and focuses >> on the real validation issues which is great. The conversion exception can >> be easily catched and maybe send to the 'Interceptors' that are also >> executed when there is a validation error. >> Doing this, the message can be adjusted and the field id can be replaced >> by the label. >> >> code could be changed to the following lines >> >>> try { >>> >>> entry.setConvertedValue(wrapped.getConvertedValue(facesContext, >>> uiComponent, o)); >>> // Start of added code >>> } catch (ConverterException ex) { >>> ValidatorException validatorException = new >>> ValidatorException( >>> ex.getFacesMessage()); >>> ExtValUtils.executeAfterThrowingInterceptors(uiComponent, >>> null, >>> o, validatorException, null); >>> resetComponentProxyMapping(); >>> throw ex; >>> // end of added code >>> } catch (RuntimeException r) { >>> resetComponentProxyMapping(); >>> throw r; >>> }* >>> * >> >> >> It isn't an ideal situation since we have to pass some null parameters to >> the method (for the MetaDataEntry en ValidationStrategy). >> >> So my questions are: >> * Do I miss something and is it possible to show the outputLabel value in >> case of a conversion error with JSF 1.1 and ExtVal? >> * The 'problem' occurs only with JSF 1.1, with 1.2 (and 2.0 of course) >> there is no problem when we use the label attribute. So is there a need for >> some specific code (for JSF 1.1 only) when newer and better versions are >> available? >> * The suggested solutions is not elegant and needs changes to the core of >> ExtVal. The use of the labelRecorder is given as an example of some >> practical usage of ExtVal and thus changes to the core are maybe to >> intrusive for this little problem. >> * Should the implementation of the ExtValRendererProxy be changed so that >> an extended class can be made easier, and thus allows the users of the >> ExtVal code solve the problem when they feel the need for it? For instance >> there is a protected empty method (processException) that subclasses can >> override do some specific handling with the caught exception. >> >> Just my thoughts, any comment and suggestions are welcome. I have also a >> small project that can be used to play a little more with the conversion >> issue. >> >> regards >> Rudy De Busscher >> >> >
