next »

[gl330k]

Hi,

I'm creating a form where I wanted to validate a credit card number in one of the form fields to see if it's a number.  The problem is that if I use integer the report results place commas in the number and if I use float then the report puts .00 at the end of the number.  Is there a way to control this output?

thanks.

[TobyL]

I'm actually a bit reluctant to give you too much help with this. If you're allowing or requiring people to enter their credit card details into your site I would expect your level of experience to be enough to work this out yourself.

What I can say is that to deal with numeric fields that you do not want to have formatted as integers or floats you can set the data type to something else and provide your own validation function for that field. See the eForm documentation in the eform/docs/ directory for validation options and on how to make functions available to eForm.

[gl330k]

Thanks,

That's what I figured; I was hoping there would be some easier way (something I missed) to pull this off.

[hotdiggity]

I just added after:

Code:

switch ($datatype){
case "integer":

Code:

case "number":

(and used "number" instead of "integer" or "float" in the form fields)

eForm definitely needs something added to output unformatted numbers, otherwise phone numbers, area codes, zips and the alike are going to look ugly formatted as thousands and decimals!

[TobyL]

Different countries use different formats for phone numbers, area and zip codes. They are not necessarily numbers. "+31 20 123456789" is a phone number for instance or "9604 RA" is a valid area code. Using your number type for those would be less than helpful, that is if you validate a number as only allowing digits and decimal point. (In which case the existing types suffice I would think)

Admittedly the formatting of the numbers perhaps should be more flexible, although if I recall correctly you can influence this by editing a value in the language files.

eForm only provides a simple set of validation types. For anything beyond that it is a simple matter of writing a custom validation function. In your validation function you can return for an invalid value, true for a valid one -or- you can return a 'formatted' value if you wish.

[hotdiggity]

Yes, agreed with phone numbers, but credit card numbers, card identification numbers, coupon codes etc look 'orrible in 000's and with 2 dec places. For simplicity's sake a basic number should be allowable. Would be interested to know more about the languages file.

eForm only provides a simple set of validation types. For anything beyond that it is a simple matter of writing a custom validation function. In your validation function you can return for an invalid value, true for a valid one -or- you can return a 'formatted' value if you wish.

Great if you're php literate!