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 Tue, 05 Jan 2010 01:19:53 GMT
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