handling non-string values in validators

Hi developers,

 I am just sweeping over some older issues which have not been 
handled yet. There are a few reports that values are passed in to the
validator which are not plain strings, as one would expect (well, at
least I do). In this case some of the validator fail.

 One case is for IntegerField's, and buried with the old sf bugtracker:

https://sourceforge.net/tracker/index.php?func=detail&aid=904435&group_id=27810&atid=391590

This one is sumbitted by Adam Patt. I have mailed with him to discuss the
topic. The problem ist that there are integer values coming out from the
request in value = REQUEST.get(key, "") for an IntegerField. 

 Interstingly this is really in the "request.form" part, not the
"request.other" thus I do not think its possible these values did came in
manually via "request.set(...)". 
 They also have not came in via rendering the fields manually, giving
them the ':int' suffix, calling Zope magic to convert them.

 I admit I have no clue from where these integer values came in the
request, but it seemed to happen.


 The other occurence is some unicode which popped in from the request;
Andy Altepeter made some short report about this at:
 
http://lists.infrae.com/pipermail/silva-dev/2004q3/001276.html

 Here it seems the 'request.get(key,"")' returned a unicode string
instead of a plain string. Well, I cannot reproduce this either, and
have no clue why this could happen.


 What do other people think about it? Does anyone have an idea how such
non-strings may happen to get in the request via Zope magic (i.e. not by
having the user stuffing them in under the "field_xxx" which I think is
a problem of the user messing with that stuff).

 There are rather easy ways to make Formulator get around these problems
by making type checks on the incoming values. Those who have reported
the problems would prefer to get these checks, but I am not so sure if
it would be a good idea; that why I am asking about it here.


Cheers,
Clemens