Nice, just one little suggestion:
Change
Object getAsObject(ConversionContext ctx, String value)
To
Object getAsObject(ConversionContext ctx, Object value)

You will still need a null check for value in your implementation, so
why not combine that with a little more generic code like
If(value instanceof String){...}else if(value instanceof
Object){...}else return null;

Maybe you will never need the Object, but if you do you will be sorry if
you only got a string to work with.

Just my 2 cents.

Maurice


-----Oorspronkelijk bericht-----
Van: Eelco Hillenius 
Verzonden: woensdag 2 februari 2005 11:37
Aan: wicket-user@lists.sourceforge.net
Onderwerp: Re: [Wicket-user] is this approach correct?

No, what I meant is that the converters were initially copied (and 
slightly altered) from the BeanUtils package. As they lacked the 
possibility of formatting (BeanUtils uses one-way converters only), I 
added support for formatting whilst not breaking the compatibility with 
BeanUtils by adding an optional interface for formatting. Now, this was 
for Baritus/ Maverick. For a large part I copied that into Wicket, as it

was one of the things in Baritus that allways functioned well. However, 
for Wicket it would be best to have a clearer interface, thus having - 
just like JSF - converters for both ways.

This is the JSF interface:

public interface Converter
{
    Object getAsObject(FacesContext context,
                       UIComponent component,
                       String value) throws ConverterException;

    String getAsString(FacesContext context,
                       UIComponent component,
                       Object value) throws ConverterException;
}

Which is tightly coupled to JSF. Furthermore, I think (by doing a quick 
code scan of MyFaces) that locales are not supported in JSF as well as 
we support it.

Currently in Wicket, these are the interfaces:

public interface IConverter
{
    public Object convert(Object value);
}

and

public interface IFormatter
{
    public String format(Object value, String pattern);
}

Now, that I have a closer look to it, I think the pattern should be 
omitted, and the interface should look like:

public interface IConverter
{
    Object getAsObject(String value) throws ConversionException;

    String getAsString(Object value) throws ConversionException;
}

However, I know from experience that use of a pattern can be very 
convenient, I am have never been very happy with the way localization is

implemented (which is again a legacy issue as I copied that from
BeanUtils.

There are several ways to tackle this. I think the most elegant - and 
future safe - option is to introduce a context object, like:

public interface IConverter
{
    Object getAsObject(ConversionContext ctx, String value) throws 
ConversionException;

    String getAsString(ConversionContext ctx, Object value) throws 
ConversionException;
}

Where ConversionContext would at least have a reference to the optional 
locale object to use (note that besides the user's locale, this can be 
explicitly set in the PropertyModel) and the optional conversion 
pattern. I think if the API looked like this, the writing of custom 
converters would be much simpler/ clearer and the lookup process would 
be drastically simplified and thus more transparent to our framework
users.

What do you think?

Eelco



Juergen Donnerstag wrote:

>>So, as that's a legacy thing
>>now, we could just as well loose the difference.
>>    
>>
>
>Sorry, it is probably only my english. Our current implementation
>isn't better nore worse than what JSF (and may be others) offer. And
>because there are "standard" packages out there to that job, the idea
>is to move towards this package. Correct?
>
>Juergen
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>Tool for open source databases. Create drag-&-drop reports. Save time
>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>_______________________________________________
>Wicket-user mailing list
>Wicket-user@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/wicket-user
>  
>



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to