Modify textfield input before validation

[pixologe]

Hi all,

How can/should modification of (textual) user input be implemented, so that it runs before validation?
(e.g. prepend a URL with "http://" if the user did not do so)

My thoughts were:

IConverter - but other threads on the list point out that it is only to be used for type conversion, not for String->String conversion.

IModel - but setObject is called after validation.

IValidator - but IValidatable has not setValue, thus modification is not possible here.

Thanks for any hints and regards

[Anatoly Kupriyanov]

As for me, I think it's better to make a client side javascript, which
do the prepend in "onchange" event.
But in your case, maybe just make a class like
class SiteUrl implements Serializable
{
  private final String url;
  public SiteUrl(final String url)
  {
    this.url = url;
  }
  public String getUrl(){return url;}
}
(or event use URL from jdk).
and implement IConverter for it.

2008/12/11 pixologe <[hidden email]>:

>
> Hi all,
>
> How can/should modification of (textual) user input be implemented, so that
> it runs before validation?
> (e.g. prepend a URL with "http://" if the user did not do so)
>
> My thoughts were:
>
> IConverter - but other threads on the list point out that it is only to be
> used for type conversion, not for String->String conversion.
>
> IModel - but setObject is called after validation.
>
> IValidator - but IValidatable has not setValue, thus modification is not
> possible here.
>
> Thanks for any hints and regards
> --
> View this message in context: http://www.nabble.com/Modify-textfield-input-before-validation-tp20952903p20952903.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
WBR, kan.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[pixologe]

Thanks for your ideas...

But.... huh... is there really no "wicket way" to achieve this?

After all I would not think that it is uncommon to fix simple things in user input before validation, e.g. trim strings, discard empty items in comma separated lists etc.

Your solutions would work both I think, I just do not like the idea of doing things like these with javascript.
Also, retrieving a String value from DB and wrapping it into an object just in order to be able to convert it back does not seem right to me...

I'll probably stick to the js solution (reluctantly ;-), but if there is really no elegant way, I would love to see one in future wicket versions.

Thanks for inspiration!
best regards

[Matthias Keller]

Hi

I had the same problem. The closest thing I found was, to create my own
instance of TextField:

    private static class MyTextField extends TextField {
       // constructors...
       protected void onComponentTag (ComponentTag tag) {
          super.onComponentTag(tag);
          String value = getValue(); // you can do anything here, for
example to display a default value if the model value was null/empty
          tag.put("value", value);
        }

        public String[] getInputAsArray () {
          String[] inputArray = super.getInputAsArray();
          if (inputArray == null || inputArray.length == 0 ||
                  StringUtils.isBlank(inputArray[0])) {
          return EMPTY_STRING_ARRAY.clone();
      }
          String value = inputArray[0].trim();
          // modify value as needed. This is executed before the validator
          inputArray[0] = value;
          return inputArray;
        }
    }

pixologe wrote:

> Thanks for your ideas...
>
> But.... huh... is there really no "wicket way" to achieve this?
>
> After all I would not think that it is uncommon to fix simple things in user
> input before validation, e.g. trim strings, discard empty items in comma
> separated lists etc.
>
> Your solutions would work both I think, I just do not like the idea of doing
> things like these with javascript.
> Also, retrieving a String value from DB and wrapping it into an object just
> in order to be able to convert it back does not seem right to me...
>
> I'll probably stick to the js solution (reluctantly ;-), but if there is
> really no elegant way, I would love to see one in future wicket versions.
>
> Thanks for inspiration!
> best regards
>  

--
[hidden email]  [phone]
Ergon Informatik AG, Kleinstrasse 15, CH-8008 Zürich
http://www.ergon.ch
______________________________________________________________
e r g o n    smart people - smart software

[Anatoly Kupriyanov]

As I remember, wicket trims spaces already, so you don't need do
anything special about it.

For DB, if you use hibernate (or if not, anyway you should have data
objects for your business entities), you can have something like that:
public class MyEntity
{
// This is mapped to database, but not for public, only database will use it.
  private String siteUrlStr;
// this is your public interface:
  public SiteUrl getSiteUrl(){return new SiteUrl(getSiteUrlStr());}
  public void setSiteUrl(SiteUrl url){siteUrlStr = url.getStr();}
}

And in code the lists should be treated as List, Collection or so, not
as comma-separated strings (only in some particular places like
persisting in database or in user interface).

2008/12/11 pixologe <[hidden email]>:

>
> Thanks for your ideas...
>
> But.... huh... is there really no "wicket way" to achieve this?
>
> After all I would not think that it is uncommon to fix simple things in user
> input before validation, e.g. trim strings, discard empty items in comma
> separated lists etc.
>
> Your solutions would work both I think, I just do not like the idea of doing
> things like these with javascript.
> Also, retrieving a String value from DB and wrapping it into an object just
> in order to be able to convert it back does not seem right to me...
>
> I'll probably stick to the js solution (reluctantly ;-), but if there is
> really no elegant way, I would love to see one in future wicket versions.
>
> Thanks for inspiration!
> best regards
> --
> View this message in context: http://www.nabble.com/Modify-textfield-input-before-validation-tp20952903p20956050.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
WBR, kan.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[pixologe]

Please note that these were just examples, not actual use cases of mine (apart from the URL stuff).

Anyway, I think there are quite some use cases where fixing/optimizing user input makes sense. I've always thought converters would be the way to go, but just recently read that they aren't.

Having stuff like this done in the domain object's setter is far to backend for my taste. As this feature addresses user interaction, I think it is rather a matter of presentation, and I would not think that my domain object should have to care. Worse, using this scenario it would not be possible to use wicket's validation behavior _after_ doing the modification. One could use a model as well, then.

kan-4 wrote

As I remember, wicket trims spaces already, so you don't need do
anything special about it.

For DB, if you use hibernate (or if not, anyway you should have data
objects for your business entities), you can have something like that:
public class MyEntity
{
// This is mapped to database, but not for public, only database will use it.
  private String siteUrlStr;
// this is your public interface:
  public SiteUrl getSiteUrl(){return new SiteUrl(getSiteUrlStr());}
  public void setSiteUrl(SiteUrl url){siteUrlStr = url.getStr();}
}

And in code the lists should be treated as List, Collection or so, not
as comma-separated strings (only in some particular places like
persisting in database or in user interface).

2008/12/11 pixologe <[e-mail]>:
>
> Thanks for your ideas...
>
> But.... huh... is there really no "wicket way" to achieve this?
>
> After all I would not think that it is uncommon to fix simple things in user
> input before validation, e.g. trim strings, discard empty items in comma
> separated lists etc.
>
> Your solutions would work both I think, I just do not like the idea of doing
> things like these with javascript.
> Also, retrieving a String value from DB and wrapping it into an object just
> in order to be able to convert it back does not seem right to me...
>
> I'll probably stick to the js solution (reluctantly ;-), but if there is
> really no elegant way, I would love to see one in future wicket versions.
>
> Thanks for inspiration!
> best regards
> --
> View this message in context: http://www.nabble.com/Modify-textfield-input-before-validation-tp20952903p20956050.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>



--
WBR, kan.

---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]

[Peter Ertl]

I really wonder why converters are not the right thing to do?

Trimming crap off the input is a one-way conversion *imho*


Am 11.12.2008 um 20:45 schrieb pixologe:

>
> Please note that these were just examples, not actual use cases of  
> mine
> (apart from the URL stuff).
>
> Anyway, I think there are quite some use cases where fixing/
> optimizing user
> input makes sense. I've always thought converters would be the way  
> to go,
> but just recently read that they aren't.
>
> Having stuff like this done in the domain object's setter is far to  
> backend
> for my taste. As this feature addresses user interaction, I think it  
> is
> rather a matter of presentation, and I would not think that my  
> domain object
> should have to care. Worse, using this scenario it would not be  
> possible to
> use wicket's validation behavior _after_ doing the modification. One  
> could
> use a model as well, then.
>
>
>
> kan-4 wrote:
>>
>> As I remember, wicket trims spaces already, so you don't need do
>> anything special about it.
>>
>> For DB, if you use hibernate (or if not, anyway you should have data
>> objects for your business entities), you can have something like  
>> that:
>> public class MyEntity
>> {
>> // This is mapped to database, but not for public, only database  
>> will use
>> it.
>>  private String siteUrlStr;
>> // this is your public interface:
>>  public SiteUrl getSiteUrl(){return new SiteUrl(getSiteUrlStr());}
>>  public void setSiteUrl(SiteUrl url){siteUrlStr = url.getStr();}
>> }
>>
>> And in code the lists should be treated as List, Collection or so,  
>> not
>> as comma-separated strings (only in some particular places like
>> persisting in database or in user interface).
>>
>> 2008/12/11 pixologe <[hidden email]>:
>>>
>>> Thanks for your ideas...
>>>
>>> But.... huh... is there really no "wicket way" to achieve this?
>>>
>>> After all I would not think that it is uncommon to fix simple  
>>> things in
>>> user
>>> input before validation, e.g. trim strings, discard empty items in  
>>> comma
>>> separated lists etc.
>>>
>>> Your solutions would work both I think, I just do not like the  
>>> idea of
>>> doing
>>> things like these with javascript.
>>> Also, retrieving a String value from DB and wrapping it into an  
>>> object
>>> just
>>> in order to be able to convert it back does not seem right to me...
>>>
>>> I'll probably stick to the js solution (reluctantly ;-), but if  
>>> there is
>>> really no elegant way, I would love to see one in future wicket  
>>> versions.
>>>
>>> Thanks for inspiration!
>>> best regards
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Modify-textfield-input-before-validation-tp20952903p20956050.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>>
>> --
>> WBR, kan.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Modify-textfield-input-before-validation-tp20952903p20963023.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[pixologe]

seems to be igor's point of view, at least:
http://www.nabble.com/append-a-converter-or-coversion-function-td15921777.html#a15964449

Peter Ertl wrote

I really wonder why converters are not the right thing to do?

[Peter Ertl]

Just because converter can convert 'from' and 'to' doesn't mean you  
can't use it for one direction only

Am 12.12.2008 um 13:01 schrieb pixologe:

>
> seems to be igor's point of view, at least:
> http://www.nabble.com/append-a-converter-or-coversion-function-td15921777.html#a15964449
>
>
> Peter Ertl wrote:
>>
>> I really wonder why converters are not the right thing to do?
>>
>
> --
> View this message in context: http://www.nabble.com/Modify-textfield-input-before-validation-tp20952903p20974347.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[pixologe]

That's right - but if the devs regard this as abuse, there's no guarantee that this still works in the next version. That's why I wondered what is the intended way of doing stuff like this.
Obviously there is none :-/

Peter Ertl wrote

Just because converter can convert 'from' and 'to' doesn't mean you  
can't use it for one direction only

Am 12.12.2008 um 13:01 schrieb pixologe:

>
> seems to be igor's point of view, at least:
> http://www.nabble.com/append-a-converter-or-coversion-function-td15921777.html#a15964449
>
>
> Peter Ertl wrote:
>>
>> I really wonder why converters are not the right thing to do?
>>
>
> --
> View this message in context: http://www.nabble.com/Modify-textfield-input-before-validation-tp20952903p20974347.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [e-mail]
> For additional commands, e-mail: [e-mail]


---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]