thx - nice to have a concrete example online! (hint: users should use http instead of https to avoid authentication.)
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/9 Rudy De Busscher <[email protected]> > > 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 >>> >>> >> >
