Re: Forms to db's and back

This WebDNA talk-list message is from

2005

It keeps the original formatting. numero = 61275
interpreted = N
texte = It sounds you are doing what I'm doing, but in my case, the table is the only code that is specific to displaying and validating the form. It tells me what I need in each field and how it should display. It tells me which field needs which validation routines. This makes it easy to re-use the page to edit any database. All I need to do is change the table and I'm all set. I can use the tools that work for editing any database (like Ken's tool or digger.tpl). But for my users, I was tired of writing a record add/edit page for every database that presented cleanly (the tools I've seen always use a text input) and validated consistently. By using the table to store the meta data (i.e. information about how to present the field for input and how to validate it), I can know that the buysell field has two options (buy or sell). I can present those in a select to make it easy for users by indicating that the type of field is a select and also ensure validation matches the options listed in the validation field (date, creditcard, unique in database, exists or not in a database. If someone hacks my form and tries to submit nonsense (for example by altering a select or a hidden field), the code is rejected based on the options in the table (which are also re-used for presentation). The validation routines are presently coded in the script for the page, but this can be changed. I basically parse the validation routines field and run through a switch/case field. Let me clean up my code this weekend and I'll email a file to you so you can see what I'm talking about. Bill-----Original Message-----From: Terry Wilson Sent: Thu, 3 Mar 2005 08:41:19 -0500To: "WebDNA Talk" Subject: Re: Forms to db's and backBill,Yes, I check my data for empty fields, formatting, etc., but I hard code my validation at the top of my pages, and display the form again if there's a problem. For instance, I wrote one that checks to make sure the date is legal; i.e., not Feb 30, for instance. Nothing goes into the DB until it passes validation. I just didn't see how tables come into play for you. Do you mean that your table is an include file with validation routines as data that get pulled out or something? That's the part that lost me.TerryAt 2:01 AM -0800 3/3/05, devaulw wrote:>scripting). The simple routine I have worked out seems to limit this problem.>The meta data is basically a table that tells the script what >validation routines are to be run, how long or short the data can >be, how it should be displayed in the form (text, hidden, textarea, >select) and things like that. I understand that I could handcode >the pages, but that is too much work since I can have meta data that >will do the work for me. By making changes in the table, the script >generates the right form and options. I use Excel to edit the >table. Every table makes a new editing page for a database. That is >far easier than handcoding.-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Associated Messages, from the most recent to the oldest:

Re: Forms to db's and back ( devaulw@onebox.com 2005)
Re: Forms to db's and back ( Terry Wilson 2005)
Re: Forms to db's and back (was Re: Displaying text and ( devaulw@onebox.com 2005)
Re: Forms to db's and back (was Re: Displaying text and ( Terry Wilson 2005)
Forms to db's and back (was Re: Displaying text and populating ( William DeVaul 2005)

It sounds you are doing what I'm doing, but in my case, the table is the only code that is specific to displaying and validating the form. It tells me what I need in each field and how it should display. It tells me which field needs which validation routines. This makes it easy to re-use the page to edit any database. All I need to do is change the table and I'm all set. I can use the tools that work for editing any database (like Ken's tool or digger.tpl). But for my users, I was tired of writing a record add/edit page for every database that presented cleanly (the tools I've seen always use a text input) and validated consistently. By using the table to store the meta data (i.e. information about how to present the field for input and how to validate it), I can know that the buysell field has two options (buy or sell). I can present those in a select to make it easy for users by indicating that the type of field is a select and also ensure validation matches the options listed in the validation field (date, creditcard, unique in database, exists or not in a database. If someone hacks my form and tries to submit nonsense (for example by altering a select or a hidden field), the code is rejected based on the options in the table (which are also re-used for presentation). The validation routines are presently coded in the script for the page, but this can be changed. I basically parse the validation routines field and run through a switch/case field. Let me clean up my code this weekend and I'll email a file to you so you can see what I'm talking about. Bill-----Original Message-----From: Terry Wilson Sent: Thu, 3 Mar 2005 08:41:19 -0500To: "WebDNA Talk" Subject: Re: Forms to db's and backBill,Yes, I check my data for empty fields, formatting, etc., but I hard code my validation at the top of my pages, and display the form again if there's a problem. For instance, I wrote one that checks to make sure the date is legal; i.e., not Feb 30, for instance. Nothing goes into the DB until it passes validation. I just didn't see how tables come into play for you. Do you mean that your table is an include file with validation routines as data that get pulled out or something? That's the part that lost me.TerryAt 2:01 AM -0800 3/3/05, devaulw wrote:>scripting). The simple routine I have worked out seems to limit this problem.>The meta data is basically a table that tells the script what >validation routines are to be run, how long or short the data can >be, how it should be displayed in the form (text, hidden, textarea, >select) and things like that. I understand that I could handcode >the pages, but that is too much work since I can have meta data that >will do the work for me. By making changes in the table, the script >generates the right form and options. I use Excel to edit the >table. Every table makes a new editing page for a database. That is >far easier than handcoding.-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ devaulw@onebox.com

DOWNLOAD WEBDNA NOW!

Re: Forms to db's and back

2005

Top Articles:

Related Readings: