Form validation problem: URGENT 
Author Message
 Form validation problem: URGENT

Hi all.

I am using tcl within StoryServer and having a problem.  I have written a
simple piece of tcl code to for each through a form element that has a comma
list of the form elements on that page that i wish to require values for.
The code is as follows:

[foreach itemVar $reqFields {
     if {[SHOW [SHOW itemVar]] == ""} {
          ...
     }

Quote:
}]

The SHOWs basically evaluate what the value of the real form element value
was that the name in the list represents.  reqFields would be something like
emailaddr city state phone

The problem is that when a large number comes across such as a credit card
number I recieve the error:

integer value too large to represent
         while executing
     "if {[SHOW [SHOW itemVar]] == ""} {
                     ...
             }"
         ("foreach" body line 4)

I need to figure out a way to get around the large numbers but still catch
the fields with no value.

Can someone who knows a hell of a lot more tcl than myself help???

Thanks in advance.
dp



Mon, 11 Mar 2002 03:00:00 GMT  
 Form validation problem: URGENT
Hi all.

I am using tcl within StoryServer and having a problem.  I have written a
simple piece of tcl code to for each through a form element that has a comma
list of the form elements on that page that i wish to require values for.
The code is as follows:

[foreach itemVar $reqFields {
     if {[SHOW [SHOW itemVar]] == ""} {
          ...
     }

Quote:
}]

The SHOWs basically evaluate what the value of the real form element value
was that the name in the list represents.  reqFields would be something like
emailaddr city state phone

The problem is that when a large number comes across such as a credit card
number I recieve the error:

integer value too large to represent
         while executing
     "if {[SHOW [SHOW itemVar]] == ""} {
                     ...
             }"
         ("foreach" body line 4)

I need to figure out a way to get around the large numbers but still catch
the fields with no value.

Can someone who knows a hell of a lot more tcl than myself help???

Thanks in advance.
dp



Mon, 11 Mar 2002 03:00:00 GMT  
 Form validation problem: URGENT

Quote:

> The SHOWs basically evaluate what the value of the real form element value
> was that the name in the list represents.  reqFields would be something like
> emailaddr city state phone

> The problem is that when a large number comes across such as a credit card
> number I recieve the error:

> integer value too large to represent
>          while executing
>      "if {[SHOW [SHOW itemVar]] == ""} {
>                      ...
>              }"
>          ("foreach" body line 4)

> I need to figure out a way to get around the large numbers but still catch
> the fields with no value.

The [if] command with comparison operators (like the == you use) tries
to convert the arguments to integers if they look like it. Your credit
card number probably exceeeded 4294967295 (see
http://purl.org/thecliff/tcl/wiki/567.html for a discussion). Checking
strings for emptyness can be saferly done with
        if {[string length [SHOW [SHOW itemvar]]]==0} {...
and string comparisons in general like
        if {[string compare [SHOW [SHOW itemvar]] ""]==0} {...
or, starting from I think Tcl 8.2,
        if [string equal [SHOW [SHOW itemvar]] ""] {...

--
Schoene Gruesse/best regards, Richard Suchenwirth - +49-7531-86 2703
RC DT2, Siemens Electrocom, Buecklestr. 1-5, D-78467 Konstanz,Germany
-------------- http://purl.org/thecliff/tcl/wiki//Richard*Suchenwirth



Tue, 12 Mar 2002 03:00:00 GMT  
 Form validation problem: URGENT


:The [if] command with comparison operators (like the == you use) tries
:to convert the arguments to integers if they look like it. Your credit

What is the benefit of doing this conversion for == and != ?  It seems like
there is much more likelihood of the wrong thing occuring than there is
of the right thing occuring...

--

<*> O- <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.



Tue, 12 Mar 2002 03:00:00 GMT  
 Form validation problem: URGENT

Quote:

> What is the benefit of doing this conversion for == and != ?  It
> seems like there is much more likelihood of the wrong thing occuring
> than there is of the right thing occuring...

Other than backward compatability, I don't see much reason for the
conversion.  I'd rather have == and != only ever operate on numerics,
for all that it would break a fair bit of my own code, let alone
everyone else's...

Donal.
--

-- The small advantage of not having California being part of my country would
   be overweighed by having California as a heavily-armed rabid weasel on our



Fri, 22 Mar 2002 03:00:00 GMT  
 Form validation problem: URGENT

Quote:

> What is the benefit of doing this conversion for == and != ?

if {03 == 3}
if {0x03 == 3}
if {" 3" == 3}

all are "true". Now, whether that's a "benefit" or not depends on your code,
I suppose.

--
Darren New / Senior Software Architect / MessageMedia, Inc.
     San Diego, CA, USA (PST).  Cryptokeys on demand.
But pity stayed his hand.  "It's a pity I've run out of
bullets," he thought.



Fri, 22 Mar 2002 03:00:00 GMT  
 Form validation problem: URGENT

Quote:


> :The [if] command with comparison operators (like the == you use) tries
> :to convert the arguments to integers if they look like it. Your credit

> What is the benefit of doing this conversion for == and != ?  It seems like
> there is much more likelihood of the wrong thing occuring than there is
> of the right thing occuring...

First, the case where the original poster's example failed should have
worked because both operands are invalid numbers.  The man page says a
string comparison is used in this case.  I'm not sure this is worth
fixing because there is no way to make the relational operators in expr
work for all possible strings.

For example:

"1 + 2" == "1      + 2"

is true for numbers but not for strings.  expr cannot determine if the
programmer meant a string comparison or a numeric one.

In the man page there are other examples that show how radix conversions
mess up the > and < operators.  The man page also suggests using "string
compare" etc. which is a step in the right direction.  IMHO the wording
could be even stronger than it is.  It should say *always* use "string
compare", "string equal", etc.

The expr string comparison feature is a carryover from older scripting
languages that were meant for login and bootup scripts, not application
development.

bob

Sent via Deja.com http://www.deja.com/
Before you buy.



Sun, 24 Mar 2002 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. newbie with a php validation form mail script problem

2. Combo-box problems in update forms. **URGENT!**

3. form refresh problem (URGENT)

4. Field Validation in a Form

5. Validation of FORM fields

6. HTML Form data validation with Object REXX (Windows)

7. Date validation of input from HTML form

8. clientside validation of checkboxes from PHP form

9. Form validation q

10. form validation

11. Form Validation

12. Form validation and page navigation

 

 
Powered by phpBB® Forum Software