I did a few obvious fixes. Other issues have to be adressed.

I fixed:
- date format (to date and to string) should allways use a dateformat instead of the deprecated parse/ String constructor
- date format allways uses the 'SHORT' dateformat type now, as in my experience, this really is the best default for web applications
- fixed NumberToString converter to use the set number format


To be done:
- currently the same number format type is used for all numbers. But for e.g. doubles, the getNumberInstance should be used.
- In NumberToStringConverter is:


   public final NumberFormat getNumberFormat()
   {
       if (numberFormat == null && locale != null)
       {
           numberFormat = NumberFormat.getInstance(locale);
       }
       return numberFormat;
   }

Problem is, that when the user's locale changes, this changes is never propogated to the converters. Easy fix would be:

   public final NumberFormat getNumberFormat()
   {
       if (locale != null)
       {
           numberFormat = NumberFormat.getInstance(locale);
       }
       return numberFormat;
   }

As NumberFormat caches locale specific instances itself, this is efficient enough.

- the other issues I mentioned last email.

Eelco



Eelco Hillenius wrote:

Jonathan Locke wrote:


i just finished a checkin of new conversion code. API is quite a bit different, so please examine it carefully.



Looks great.

There's a few problems however. Localization doesn't work well currently. To test this, you can go to the forminput example and select e.g. the dutch locale.

* a double like 20,5 is valid input. 20.5 (currently) is the same as 205. NumberToStringConverter should be:

   public Object convert(final Object value)
   {
       NumberFormat fmt = getNumberFormat();
       if (fmt != null)
       {
           return fmt.format(value);
       }
       return value.toString();
   }

* (using the above fix), when I save 20,5 the ,5 is thrown away and 20 is saved
* the date is not formatted properly
* when the form is saved, the date disappears without any error message displaying
* 100,5 should be marked as an invallid integer


Eelco


i spent all day today working on this, so please ask questions before tweaking anything. i'm pretty sure i got this right.


major changes:

- folded localization into a single converter hierarchy

- implemented converters for all primitive types plus Date and String

- introduced ITypeConverter interface for conversions TO some implicit type. this is mainly of
interest internally, since the IConverter interface is more general and useful. but use of type
converters directly is supported and some mucking with ITypeConverters may be necessary
to configure format/parse patterns for locales for your application.


- refactored and simplified Component and TypeValidator to use the new conversion code
this should all be automatic goodness!


pseudo code example of converter API (again, if you're using TypeValidator, you may not even
need to know this):


IConverterFactory f = new ConverterFactory();
IConverter c = f.newConverter();

String s = c.convert(new Integer(5), String.class);
Integer i = c.convert("5", Integer.class);

c.setLocale(Locale.DUTCH);
String s = (String)c.convert(new Date(), String.class);
Date d = (Date)c.convert("10-okt-2002", Date.class);

individual conversions can be registered on the Converter class by the factory,
which is something most people won't generally need to do since
by default conversions are made available for all Java language primitive types
and their enclosing first class objects. also conversions to and from Date and
String are supported. all these conversions will respect Locale if you set it
on the converter and each converter's format can be set if you don't like the
default format for the locale.


conversions to String are somewhat more complex internally and involve registering
string formatting converters (which still implement the same ITypeConverter
interface) on the StringConverter object. this is really quite elegant and allows
for any arbitrary formatting when converting objects to strings. currently locale
formatting for Date and Number types is supported.




-------------------------------------------------------
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-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop





------------------------------------------------------- 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-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop




-------------------------------------------------------
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-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop

Reply via email to