Displaying text and populating form fields ...

This WebDNA talk-list message is from

2005

It keeps the original formatting. numero = 61137
interpreted = N
texte = My relatively good (but not guaranteed) tests confirm the following:DISPLAYING TEXT ON THE PAGE:1- To display text on the page from a db field --> use [convertchars] if the db field might have VT (vertical tab) characters, or use it all the time just to be safeWhy? Because VT's are converted to
's by [convertchars] thus if you want the db value to display properly on the page -- complete with the original line breaks -- you will use [convertchars] to insure that those line breaks will display properly. Of course [convertchars] converts other characters so they display properly on the page as well, I only mention the VT conversion because it is one of the critical conversions that people will notice immediately, and one critical issue is enough as far as I'm concerned.2- To display text on the page from a text formvariable --> don't do anything!Why? Because unless my tests have missed something (and this is entirely possible) there are no common characters that can be entered via the keyboard that need to be converted. My tests show that &<> are changed to &<> by [convertchars], and these same changes plus " to " are performed by [input]. But none of these are necessary when displaying text on the page, thus my conclusion that nothing needs to be done to the formvariable value in this situation. Of course it won't hurt to use either [convertchars] or [input] here either (from what I can see) so if anyone knows a character that can be entered into a text field and passed to the next page and that *must* be converted so it doesn't mess up the display, please tell me.3- To display text on the page from a textarea formvariable --> use [grep search=%0B&replace=
]Why? Because the StandardConversions.db used by default with [convertchars] does not have a %0D to
conversion in it, and there is no other context in webdna that deals with this situation exclusively (without possibly creating other undesirable effects). Of course you can change the StandardConversions.db file by adding this conversion to it, then you can possibly use [convertchars] instead of [grep]. But when you change a default database that's used by webdna, this might screw up something else (or will it?). Therefore another option might be to create a special database so you can use [convertchars db=special.db] in case more than one character needs to be converted. But if it can be proven that no other characters need to be changed, the grep solution looks to be the easiest to implement.POPULATING FORM FIELDS - GENERAL GUIDELINE:4- Do not use [url] when populating form fields.Why? Because the reason for populating form fields is *usually* to show you existing data that may need to be changed ... and no one wants to see a bunch of urled text in a form field when they are trying to review unurled data.POPULATING FORM FIELDS FROM A DATABASE:5- To populate a text field from a db field --> use [input] every timeWhy? Because text fields do not display any text after the first VT character, so if there is any possibility that the db field might have a VT character in it, it's best to use [input].6- To populate a textarea field from a db field --> use [input] every timeWhy? Because [input] converts VT's in the db back to line breaks so they will display properly in the textarea field. Of course [input] does other required conversions as well, I'm only mentioning this one because it is a critical one, and one critical conversion should be enough to suggest that the use of [input] is the best decision here.7- To populate a hidden field from a db field --> use [input] every timeWhy? Because [input] converts VT's properly (same reason as #5 and#6 above).POPULATING FORM FIELDS FROM FORMVARIABLES:8- To populate a text field from a formvariable --> use [input] every timeWhy? Because text fields do not display any text after the first quote character in the value, so if there's any possibility that the db field might have a quote character in it, it's best to deal with it by using [input].9- To populate textarea field from a formvariable --> use [input] every timeWhy? I don't know because my tests did not prove that this is necessary, but that's probably because I failed to test for certain characters that might possibly screw things up. Anyways, when developing a set of "standard coding rules" it's nice to be consistent, and using [input] when populating all textarea fields is about as consistent as you can get. Besides, using [input] does not create any problems, but it just might prevent some if it is used consistently, right?10- To populate a hidden field from a formvariable --> use [input] every timeWhy? Because [input] fixes the quote character problem in a hidden field just like in a text field (same reason as #8 above).CONCLUSIONS:Please note that the following rules (I guess I should call them 'guidelines' instead) and my conclusions assume that "method=post" is used in all forms (because I never use method=get in my forms) and that the "wrap" attribute is not specified in textarea fields. Since browsers default to wrap=soft or wrap=virtual, I figure that using these attributes will not change anything.So here's a summary of my set of standard coding rules for use when displaying data on the page and when populating form fields. 1- To display text on the page from a db field --> use [convertchars]2- To display text on the page from a text formvariable -- don't use anything3- To display text on the page from a textarea formvariable -- use [grep search=%0B&replace=
]4- To populate any text or textarea or hidden field from a db field or from a formvariable --> use [input] every timeNow that I've said all this, I would appreciate it if anyone can give me a specific example of any situation that these 'guidelines' will not deal with properly. I'm not afraid to be proven wrong here because I'm not trying to prove myself 'right' about any of this anyways.All I really want is to come up with a definitive set of rules for coding in these situations. If we can work together to test every possible situation, maybe we can actually come up with a comprehensive set of guidelines to refer to from now on. SMSI is not going to do this for us, so let's do it ourselves. It shouldn't take that much effort, right?:)Thanks.-- Sincerely,Kenneth Gromewww.kengrome.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:

Displaying text and populating form fields ... ( Kenneth Grome 2005)

My relatively good (but not guaranteed) tests confirm the following:DISPLAYING TEXT ON THE PAGE:1- To display text on the page from a db field --> use [convertchars] if the db field might have VT (vertical tab) characters, or use it all the time just to be safeWhy? Because VT's are converted to
's by [convertchars] thus if you want the db value to display properly on the page -- complete with the original line breaks -- you will use [convertchars] to insure that those line breaks will display properly. Of course [convertchars] converts other characters so they display properly on the page as well, I only mention the VT conversion because it is one of the critical conversions that people will notice immediately, and one critical issue is enough as far as I'm concerned.2- To display text on the page from a text formvariable --> don't do anything!Why? Because unless my tests have missed something (and this is entirely possible) there are no common characters that can be entered via the keyboard that need to be converted. My tests show that &<> are changed to &<> by [convertchars], and these same changes plus " to " are performed by [input]. But none of these are necessary when displaying text on the page, thus my conclusion that nothing needs to be done to the formvariable value in this situation. Of course it won't hurt to use either [convertchars] or [input] here either (from what I can see) so if anyone knows a character that can be entered into a text field and passed to the next page and that *must* be converted so it doesn't mess up the display, please tell me.3- To display text on the page from a textarea formvariable --> use [grep search=%0B&replace=
]Why? Because the StandardConversions.db used by default with [convertchars] does not have a %0D to
conversion in it, and there is no other context in webdna that deals with this situation exclusively (without possibly creating other undesirable effects). Of course you can change the StandardConversions.db file by adding this conversion to it, then you can possibly use [convertchars] instead of [grep]. But when you change a default database that's used by webdna, this might screw up something else (or will it?). Therefore another option might be to create a special database so you can use [convertchars db=special.db] in case more than one character needs to be converted. But if it can be proven that no other characters need to be changed, the grep solution looks to be the easiest to implement.POPULATING FORM FIELDS - GENERAL GUIDELINE:4- Do not use [url] when populating form fields.Why? Because the reason for populating form fields is *usually* to show you existing data that may need to be changed ... and no one wants to see a bunch of urled text in a form field when they are trying to review unurled data.POPULATING FORM FIELDS FROM A DATABASE:5- To populate a text field from a db field --> use [input] every timeWhy? Because text fields do not display any text after the first VT character, so if there is any possibility that the db field might have a VT character in it, it's best to use [input].6- To populate a textarea field from a db field --> use [input] every timeWhy? Because [input] converts VT's in the db back to line breaks so they will display properly in the textarea field. Of course [input] does other required conversions as well, I'm only mentioning this one because it is a critical one, and one critical conversion should be enough to suggest that the use of [input] is the best decision here.7- To populate a hidden field from a db field --> use [input] every timeWhy? Because [input] converts VT's properly (same reason as #5 and#6 above).POPULATING FORM FIELDS FROM FORMVARIABLES:8- To populate a text field from a formvariable --> use [input] every timeWhy? Because text fields do not display any text after the first quote character in the value, so if there's any possibility that the db field might have a quote character in it, it's best to deal with it by using [input].9- To populate textarea field from a formvariable --> use [input] every timeWhy? I don't know because my tests did not prove that this is necessary, but that's probably because I failed to test for certain characters that might possibly screw things up. Anyways, when developing a set of "standard coding rules" it's nice to be consistent, and using [input] when populating all textarea fields is about as consistent as you can get. Besides, using [input] does not create any problems, but it just might prevent some if it is used consistently, right?10- To populate a hidden field from a formvariable --> use [input] every timeWhy? Because [input] fixes the quote character problem in a hidden field just like in a text field (same reason as #8 above).CONCLUSIONS:Please note that the following rules (I guess I should call them 'guidelines' instead) and my conclusions assume that "method=post" is used in all forms (because I never use method=get in my forms) and that the "wrap" attribute is not specified in textarea fields. Since browsers default to wrap=soft or wrap=virtual, I figure that using these attributes will not change anything.So here's a summary of my set of standard coding rules for use when displaying data on the page and when populating form fields. 1- To display text on the page from a db field --> use [convertchars]2- To display text on the page from a text formvariable -- don't use anything3- To display text on the page from a textarea formvariable -- use [grep search=%0B&replace=
]4- To populate any text or textarea or hidden field from a db field or from a formvariable --> use [input] every timeNow that I've said all this, I would appreciate it if anyone can give me a specific example of any situation that these 'guidelines' will not deal with properly. I'm not afraid to be proven wrong here because I'm not trying to prove myself 'right' about any of this anyways.All I really want is to come up with a definitive set of rules for coding in these situations. If we can work together to test every possible situation, maybe we can actually come up with a comprehensive set of guidelines to refer to from now on. SMSI is not going to do this for us, so let's do it ourselves. It shouldn't take that much effort, right?:)Thanks.-- Sincerely,Kenneth Gromewww.kengrome.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/ Kenneth Grome

DOWNLOAD WEBDNA NOW!

Displaying text and populating form fields ...

2005

Top Articles:

Related Readings: