next message in archive
next message in thread
previous message in archive
previous message in thread
Index of Subjects
Index of Subjects Hi Jonathan, We probably should look at adding more data/error checking functionality that could be used in various situations. I would probably try to include it as a set of library functions and possibly do something like have the postal code function check on Canadian and US or some such.... I noticed the other day that the 'amount' entry field in memfind does no error checking and that it was possible to enter both: '01234.55' and '333.333' in the amount field... which then (on dev) gets sent along to the bank functions.... ;-( --- The actual requirement for error checking varies from situation to situation. - obviously with something like membership type and expiry date we need very strict adherence to the database standard... - with others such as custom user logins we need to check that the name is not already in use, that it doesn't contain 'non-allowed' characters, is not too long, etc... - at various times we've refused a password that we deemed (dictionary lookup) to be too easy to guess.... - and, in some situations we have tolerated possible errors ...it's almost impossible to validate an organization's name. --- We should keep in mind that error checking carries additional programing overhead. We have to build in (and the hardest part, 'comment'... ;-) the necesary logic structures. And, especially when prototyping functionality it's much quicker to just accept what the user input... usually we have then gone on to add error checking as the need for it became clear... and we had a better sense of whether we should/could test the whole record and spit out multiple errors or test a few data items, and then test a few more... I don't think any error messages can be considered friendly... ;-) --- And last (in this quick list) is considering who is filling in the data... if office personnel or editors are using a form on a regular basis they can usually deal with more rigorous data checking because they quickly learn to avoid the pitfalls... A user who only might only use a form once needs to be considered in a different light as they could easily be confused and frustrated by rigorous data checking ...especially if the data entry form does not clearly communicate the requirement... Which becomes more important as we produce forms that are completed by people who are not as comfortable with technical language, or who do not posess a similar cultural background (e.g. those for whom English is not their first language). --- _My_ _general_ approach would be to: - use as _little_ data checking as we can get away with... - develop a library of data checking fuctions that will allow programmers to grab the answer quickly, and locate it somewhere so it can be changed to accomodate [multiple|other] [currencies|postal code systems|etc] as necessary. The nice thing about doing this king of stuff in gawk or shell is that we have the ability to use the 'international' functions and have messages returned in the language of the user/site... I have no knowledge of what internationalization functions are available in Perl or php... can anyone speak to this? david potter On Fri, 18 Aug 2000, Johnathan Thibodeau wrote: > Hey, I've got a few things that might be worth looking into. > > ######Postal Code##### > I created an IP (ip-1096), The Combined Presence of Internet Programmers > (TCP/IP). For a postal code I entered in 555 %%%, and it took it. A valid > Canadian postal code is always L#L #L# (letter number letter space > number letter number). All postal code in Nove Scotia start with a B, and > all in Halifax have the next number 3 (I know, not everbody is as > fasinated by the postal system as I am). > > My point is that this would be easy to check for, the format anyway (if > your really daring you can check it out against Canada Post's online > datebase :). > > But what about the Americans. If you wanted to let US groups get accounts > (have we ever had any in the past?), the you could just accept alphanum > characters. > > ######Liason Email##### > With the same account I set the liason email to be (555) 555-5555, not > good. This is a more likely error because there are usually two > teletphone fields, and the field above it the Liaison Telephone field, > minds can get mixed up and enter the phone number twice, the second time > into the e-mail field. > > Filtering e-mail addresses it a snap > ([[:alnum:]]+@[[:alnum:]]+\.[[:alnum:]]+[[:alnum:].], or somthing like > that). Again if your feeling really ambitious, you can check the username > against the host :). > > I'm not done checking yet, but I'll keep trying. > > Johnathan > > On Thu, 17 Aug 2000, David L. Potter wrote: > > > > > Hi Mark (and ChrisM) > > > > I've created an htpassword account for both of you on dev using your CCN > > login (Mark, aa051) and through computer magic the same password as you > > are using on CCN (whatever that is). > > > > The new functionality that I've developed can be accessed via: > > > > http://dev.chebucto.ns.ca/cgi-ipbin/newip > > > > These accounts should also work for the functions Giselle has been > > working on, I'll leave it to her to identify the entry points... > > > > dlp > > > > > > > > On Thu, 17 Aug 2000, Mark Ronald Rushton wrote: > > > > > > > > Hi David et al., > > > > > > Apologies - it's a bad time for me right now. I'll try to get in on the > > > weekend and poke around ;-) > > > > > > Mark > > > > > > > > > -------------------------------------- > > > Mark Rushton > > > Community Support & Development Editor > > > Chebucto Community Network (CCN) > > > http://chebucto.ns.ca/~Mark/ > > > -------------------------------------- > > > > > >
next message in archive
next message in thread
previous message in archive
previous message in thread
Index of Subjects