[ 
https://issues.apache.org/jira/browse/TOMAHAWK-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879593#action_12879593
 ] 

Leonardo Uribe commented on TOMAHAWK-1508:
------------------------------------------

I reviewed both components and the problem for use Converter interface reside 
in its design vs t:inputCalendar and t:inputDate requeriments. It has two 
problems:

- It assume submittedValue is always a String, but for t:inputDate that is not 
true. For this case as suggested, we need a property to give the chance to 
convert the java.util.Date instance used by the component to other type and 
viceversa.

- t:inputCalendar and t:inputDate requires a base "date type" to manipulate. In 
both cases is java.util.Date, but the boundaries between the base date type and 
the business type are not clear. For example, in jdk 1.6 java.sql.Date that 
extends from java.util.Date override some methods and makes t:inputCalendar and 
t:inputDate fail. To show the point, i did a small example and the exception 
thrown was:

javax.faces.FacesException: Exception while setting value for expression : 
#{calendarBean.thirdDate} of component with path : {Component-Path : [Class: 
javax.faces.component.UIViewRoot,ViewId: /calendar.jsp][Class: 
javax.faces.component.html.HtmlPanelGroup,Id: body][Class: 
javax.faces.component.html.HtmlForm,Id: calendarForm2][Class: 
org.apache.myfaces.custom.calendar.HtmlInputCalendar,Id: thirdOne]}
        at 
javax.faces.component.UIInput.queueExceptionInRequest(UIInput.java:371)
        at javax.faces.component.UIInput.updateModel(UIInput.java:353)
        at javax.faces.component.UIInput.processUpdates(UIInput.java:258)
        at javax.faces.component.UIForm.processUpdates(UIForm.java:127)
        at 
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:799)
        at 
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:799)

Caused by: java.lang.IllegalArgumentException: Cannot convert 17/06/10 12:00 AM 
of type class java.util.Date to class java.sql.Date
        at com.sun.el.lang.ELSupport.coerceToType(ELSupport.java:381)
        at com.sun.el.parser.AstValue.setValue(AstValue.java:164)
        at com.sun.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:269)
        at javax.faces.component.UIInput.updateModel(UIInput.java:336)

In TOMAHAWK-1508.patch there is a proposal to solve this problem. The idea is 
create an interface called DateBusinessConverter with two methods:

    public Object getBusinessValue(FacesContext context,
                       UIComponent component,
                       java.util.Date value);

    public java.util.Date getDateValue(FacesContext context,
                       UIComponent component,
                       Object value);

The idea is use getBusinessValue() to convert the java.util.Date instance 
calculated from submittedValue, so the resulting object will be used later as 
the converted value and validation.

Then, getDateValue() is used to retrieve the value stored in the business bean 
and convert it in a representation that t:inputCalendar and t:inputDate can 
manipulate.

The default DateBusinessConverter has this code:

    public Object getBusinessValue(FacesContext context, UIComponent component,
            Date value)
    {
        ValueBinding vb = component.getValueBinding("value");
        Class type = vb.getType(context); 
        if (type != null)
        {
            if (java.sql.Date.class.isAssignableFrom(type))
            {
                return new java.sql.Date(value.getTime());
            }
        }
        return value;
    }

    public Date getDateValue(FacesContext context, UIComponent component,
            Object value)
    {
        if (value instanceof java.sql.Date)
        {
            //Convert to strict java.util.Date
            return new Date(((java.sql.Date)value).getTime());
        }
        return (Date) value;
    }

In few words, it allows use java.util.Date and java.sql.Date in a better and 
more predictable way, so with this fix, both java.util.Date and java.sql.Date 
will supported out of the box.

To make this fix work, it is necessary to do proper stuff in jsp Tag class and 
facelet TagHandler. The property "dateBusinessConverter" works like this:

- If the value is literal, look for the mentioned class instance, create a new 
instance and assign to the component property.
- If it the value a EL Expression, set the expression to the component property.

I think we can enhance this approach in the future, but for now I think it is 
better to keep things simple, commit the code and in the future think about it.

If no objections I'll commit the code soon.

> Find a way to convert between the model type required for the renderer, and 
> the model-type that the backing-beans use for t:inputCalendar and t:inputDate
> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TOMAHAWK-1508
>                 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1508
>             Project: MyFaces Tomahawk
>          Issue Type: Improvement
>          Components: Calendar, Date
>    Affects Versions: 1.1.9
>            Reporter: Leonardo Uribe
>            Assignee: Leonardo Uribe
>         Attachments: TOMAHAWK-1508.patch
>
>
> From TOMAHAWK-1425:
> Hi Leonardo,
> I have always thought that JSF should add a business-converter for such 
> issues. So we should have a way to convert between the model type that we 
> need for the renderer, and the model-type that the backing-beans use.
> You could register such a converter on the input-component like the normal 
> converter, businessConverter="...". We could also cover stuff like the 
> joda-date with this.
> Eventually, we could even add a central registry for this in MyFaces where 
> you can register business-converters centrally and hence let the renderer 
> automatically retrieve such a a converter for the backing-bean datatype and 
> the datatype it needs.
> best regards,
> Martin 
> We'll explore this idea here

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to