We already try to guess the type if the user doesn't set it (but not in
constructor but much later when the component/model hierarchy is completed)
But if the type is a String.class we will not set it and ignore it.
So you shouldn't set the type to String.class by default, only set it when
you really want a String to String conversion.
johan
On Mon, Mar 31, 2008 at 3:46 PM, Eric Rotick <[EMAIL PROTECTED]> wrote:
> I guess, if this was a real issue then more users would have reported it.
> However, as a TextField is such an innocent component then any confusing
> behaviour should be addressed. Maintaining a common behaviour of
> setConvertEmptyInputStringToNull would do that and your proposed solution
> looks good.
>
> One thing which was confusing from the javadocs level is the implication
> that the setting of a type is defaulted; i.e.
>
> public TextField( String id, Class type ) {
> super( id );
> setType( type );
> ...
> }
>
> public TextField( String id ) {
> super( id );
> Class type = workOutTypeFromModelIfPossible( );
> if( type == null ) {
> type = String.class;
> }
> setType( type );
> ...
> }
>
> In other words, there is always a type set unless the model is one which
> does not allow for it to be derived in which case String is assumed as in
> the FormComponent javadocs for setType.
>
> Eric.
>
> On Mon, Mar 31, 2008 at 1:37 PM, Johan Compagner <[EMAIL PROTECTED]>
> wrote:
>
> > Ok i guess if if quickly look at the code.
> > If you dont do your own converter then it defaults i guess to the
> > DefaultConverter
> > that does this:
> >
> > public Object convertToObject(String value, Locale locale)
> > {
> > if (value == null)
> > {
> > return null;
> > }
> > if ("".equals(value))
> > {
> > if (((Class)type.get()) == String.class)
> > {
> > return "";
> > }
> > return null;
> > }
> >
> > So if it is a String class and the input is "" it does return ""
> >
> > we could change this:
> >
> > final IConverter converter = getConverter(getType());
> > try
> > {
> > convertedInput = converter.convertToObject(getInput(),
> > getLocale());
> > }
> >
> > in FormComponent..
> > If it is of Type String then after the conversion we still check for the
> > convert empty to null and do that..
> >
> > Because now that boolean is of no use if you are setting the Type
> >
> > johan
> >
> > johan
> >
> >
> > On Mon, Mar 31, 2008 at 2:34 PM, Johan Compagner <[EMAIL PROTECTED]>
> > wrote:
> >
> > > if you are setting the type The converter is called and not
> > > convertValue()
> > > i am still not really happy with this but for 1.3/1.4 this is the way
> it
> > > works
> > >
> > > And i guess the String converter that does String to String doesnt óok
> > at
> > > that convert empty input to null value at all
> > >
> > > Do you have your own?
> > >
> > > johan
> > >
> > >
> > >
> > > On Mon, Mar 31, 2008 at 1:38 PM, Eric Rotick <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > > I do have the type set and I've been reading WICKET-606 and I'm
> using
> > > > 1.3.2and there is no converter and convertInput is not called.
> > > >
> > > > I've now written some code to show that there is a difference.
> > > >
> > > > form.add( new TextField( "text1", new PropertyModel( this, "text1" )
> )
> > > > );
> > > > form.add( new TextField( "text2", new PropertyModel( this, "text2" )
> > > > ).setConvertEmptyInputStringToNull( true ) );
> > > > form.add( new TextField( "text3", new PropertyModel( this, "text3" )
> > > > ).setConvertEmptyInputStringToNull( false ) );
> > > > form.add( new TextField( "text4", new PropertyModel( this, "text4"
> ),
> > > > String.class ) );
> > > > form.add( new TextField( "text5", new PropertyModel( this, "text5"
> ),
> > > > String.class ).setConvertEmptyInputStringToNull( true ) );
> > > > form.add( new TextField( "text6", new PropertyModel( this, "text6"
> ),
> > > > String.class ).setConvertEmptyInputStringToNull( false ) );
> > > >
> > > > produces this
> > > >
> > > > Setting text1 to [null]
> > > > Setting text2 to [null]
> > > > Setting text3 to []
> > > > Setting text4 to []
> > > > Setting text5 to []
> > > > Setting text6 to []
> > > >
> > > > So,
> > > >
> > > > - text1 and text2 are the same because
> > > > setConvertEmptyInputStringToNull is true by default
> > > > - text3 does what would be expected
> > > > - text4 I'm not sure about
> > > > - text5 and text6 are anomalous as either one or the other should
> > > > produce a null
> > > >
> > > > I guess the main problem is that I'm not sure what is supposed to
> > > > happen. I
> > > > though that having set the type to String meant that the normal
> string
> > > > processing took place and setConvertEmptyInputStringToNull did the
> > job.
> > > >
> > > > As it is, I've learned more about how things work and I can overcome
> > my
> > > > problem. However, if anyone wants me to continue with this I would
> be
> > > > happy
> > > > to do so.
> > > >
> > > > Eric.
> > > >
> > > > On Fri, Mar 28, 2008 at 8:58 PM, Johan Compagner <
> [EMAIL PROTECTED]
> > >
> > > > wrote:
> > > >
> > > > > Are you sure you dont have the type set?
> > > > > Is a converter used or is convertInput called?
> > > > >
> > > > > On 3/28/08, Eric Rotick <[EMAIL PROTECTED]> wrote:
> > > > > > Hmm, it's not working for me.
> > > > > >
> > > > > > There's one other thing I spotted. The docs say that a TextField
> > > > > defaults to
> > > > > > String.class even if it cannot work out the class from the
> model.
> > My
> > > > > model
> > > > > > is not one that allows for reflection to determine the class and
> > > > > initially
> > > > > > all input to the TextField was being set as null even when there
> > was
> > > > > some.
> > > > > > As soon as I added the parameter to set the class to String it
> > > > started
> > > > > > saving strings correctly.
> > > > > >
> > > > > > I will have a look at the code to see if there's anything
> obvious.
> > > > > >
> > > > > > Eric.
> > > > > >
> > > > > > On Fri, Mar 28, 2008 at 4:37 PM, Igor Vaynberg <
> > > > [EMAIL PROTECTED]>
> > > > > > wrote:
> > > > > >
> > > > > > > TexField.setConvertEmptyInputStringToNull( true ) worked fine
> > for
> > > > me
> > > > > > > in a quickstart...
> > > > > > >
> > > > > > > -igor
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Mar 28, 2008 at 8:25 AM, Eric Rotick <
> > [EMAIL PROTECTED]
> > > > >
> > > > > wrote:
> > > > > > > > I've just been reading the section on Forms and validation
> in
> > > > Wicket
> > > > > in
> > > > > > > > Action and have tried
> > > > > > > >
> > > > > > > > AbstractValidator av = new AbstractValidator( ) {
> > > > > > > > protected void onValidate( IValidatable validatable
> )
> > {
> > > > > > > > // No nothing
> > > > > > > > }
> > > > > > > > public boolean validateOnNullValue( ) {
> > > > > > > > return true;
> > > > > > > > }
> > > > > > > > };
> > > > > > > >
> > > > > > > > adding one of these to the TextField but still an empty
> > string
> > > > gets
> > > > > > > > returned.
> > > > > > > >
> > > > > > > > All I want to do is get a null string rather than an empty
> > > > string
> > > > > from
> > > > > > > a
> > > > > > > > TextField. Has nobody had this use case?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Thu, Mar 27, 2008 at 5:02 PM, Eric Rotick <
> > > > [EMAIL PROTECTED]>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > I've just realised that the database is getting filled
> with
> > > > > columns
> > > > > > > of
> > > > > > > > > empty strings which then don't cause the 'not null' test
> to
> > > > trip.
> > > > > > > > >
> > > > > > > > > The culprit is the TextField returning an empty string
> > rather
> > > > > than a
> > > > > > > null.
> > > > > > > > > I can see there are some special considerations for
> > returning
> > > > a
> > > > > null
> > > > > > > and I
> > > > > > > > > want to understand how they will effect me. However, I've
> > > > tried
> > > > > > > > >
> > > > > > > > > TexField.setConvertEmptyInputStringToNull( true )
> > > > > > > > >
> > > > > > > > > with no effect and using
> > > > > > > > >
> > > > > > > > > new TextField( id ) {
> > > > > > > > > public boolean isInputNullable() {
> > > > > > > > > regturn true;
> > > > > > > > > }
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > also with no effect.
> > > > > > > > >
> > > > > > > > > I'm assuming I'm not the first person to see this effect
> > and
> > > > I
> > > > > guess
> > > > > > > it's
> > > > > > > > > lack of understanding rather than some implicit behaviour
> > but
> > > > I
> > > > > can't
> > > > > > > find
> > > > > > > > > anything guiding on the subject.
> > > > > > > > >
> > > > > > > > > In this case, the string has no special formatting, it
> just
> > > > needs
> > > > > to
> > > > > > > be
> > > > > > > > > stored verbatim in the database but the application logic
> > in
> > > > the
> > > > > > > backend
> > > > > > > > > uses an empty string in a different way than a null
> string
> > > > and,
> > > > > yes,
> > > > > > > maybe
> > > > > > > > > the database should also have a column check but it
> doesn't
> > > > at
> > > > > > > present.
> > > > > > > > >
> > > > > > > > > Any pointers?
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > >
> ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
