ericht->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
BeanUti
;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 th
7
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
>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@li
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
Juergen Donnerstag wrote:
I'm not very deep in that piece of code, but I like the idea of having
just one interface to format and convert the data.
Pattern: would it be used to temporarily replace a default pattern (e.g. Date)?
Not nescesarily replace. The converter could (optionally!) use this
I'm not very deep in that piece of code, but I like the idea of having
just one interface to format and convert the data.
Pattern: would it be used to temporarily replace a default pattern (e.g. Date)?
ConversionContext: Would it be automatically created and initialized
with lets say the current
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 a
> 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
That makes sense; it would then be like the converters in JSF. These
converters came from another project (Baritus) which had them largely
based on the commons BeanUtils package. So, as that's a legacy thing
now, we could just as well loose the difference.
If everyone (devs) are +1 with this, I
Thanks Eelco. It was not clear to me that a Formatter is the opposite
of a Converter but your info helps.
I wonder if this could all be more intuitive. My first reaction is
that it might be less confusing if Converters did both directions and
the Formatter concept went away. Maybe ICo
Ooops: 'Because I added a type converter, ...' should have been:
'Because I added a TypeValidator, ...'.
Eelco
Eelco Hillenius wrote:
Yep. That's the nicest way to do it.
You probably want to use this setting (false by default):
settings.setPropertyModelDefaultApplyFormatting(true);
as then the c
Yep. That's the nicest way to do it.
You probably want to use this setting (false by default):
settings.setPropertyModelDefaultApplyFormatting(true);
as then the converting works both ways.
If you take a look at the forminput example (CVS HEAD), you'll see:
TextField dateInput = new Text
I want to have a text form field that converts to a Date
attribute on a bean (using the -MM-DD string format).
It looks like I would create a DateConverter implementation of
IConverter and register it with the ConverterRepository so that the
PropertyModel instance can convert it appropr
14 matches
Mail list logo
