myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: [ExtVal] Conversion error, JSF 1.1 and ExtVal
Date Sat, 09 Jan 2010 14:47:24 GMT
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 <rdebusscher@gmail.com>

>
> 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 <gerhard.petracek@gmail.com>
>
> 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 <rdebusscher@gmail.com>
>>
>> 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
>>>
>>>
>>
>

Mime
View raw message