numero = 56859
interpreted = N
texte = I go even a step further than Ken says here... I use [input] for the values of ALL form fields - including on hidden fields, checkboxes, select options, etc. - except when I'm absolutely sure no problematic characters are involved. The main killer I've encountered is double-quote characters, which mess up the HTML. Given this: [text]name=bob "the man" smith[/text] the quote before "the" will terminate the quoted value for the "value" parameter, resulting in a value of "bob " in the field. Using fixes this. More than just site visitor data entry, I get this sort of situation in admin forms when my clients do things like enter product names that contain quotes, often using them to denote inches in their product names. - brian On Mar 15, 2004, at 4:58 PM, Kenneth Grome wrote: >>>> For the sake of discussion, when is it not appropriate to wrap >>>> parameters or user input in [url] tags? >>> >>> In forms you should always put the values inside input contexts, not >>> url contexts. >> >> Well, yes, [input] for displaying textarea values. > > Not just for textarea fields, for regular text fields too. This is a > good standard practice because (for example): > > 1- If you import your db from another source and if any value in any > field *might* have a converted CR character in it, you will need the > input context to keep your form field from 'breaking' if you use > values in that field to populate regular text fields in the form. > > 2- I haven't tested this (or maybe I have and that's why I'm thinking > about it now) but I think it is possible to 'copy and paste' a CR into > a regular text field even though you cannot physsically type a CR into > a text field directly. If this is true, the CR that you 'copied and > pasted' into that field will end up in a database field that you > thought would never contain this kind of character. Thus when you use > this value to populate a text field in a form, that field will break > unless you have put it inside an input context. > > 3- If you use a textarea field for data input and you write that data > to a db, then later you 'change your forms' and decide to use a > regular text field to display the data from this field, the CR's that > were entered while using the textarea field will still be in the db > and therefore you will need to use an input context to populate your > text field with this data to prevent the form from breaking. > > Are there other situations in which a CR might be saved to a db field > without your knowing or expecting it? If so, these would be even more > good reasons to use input in all your form fields that display data, > not just the textarea values. > > -- > > Kenneth Grome > WebDNA Programmer > Outsource Service Provider > Phone: +6332 255-6591 > > ------------------------------------------------------------- > 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: Confused about Grep Syntax ( Brian Fries 2004)
I go even a step further than Ken says here... I use [input] for the values of ALL form fields - including on hidden fields, checkboxes, select options, etc. - except when I'm absolutely sure no problematic characters are involved. The main killer I've encountered is double-quote characters, which mess up the HTML. Given this: [text]name=bob "the man" smith[/text] the quote before "the" will terminate the quoted value for the "value" parameter, resulting in a value of "bob " in the field. Using [input][name][/input]"> fixes this. More than just site visitor data entry, I get this sort of situation in admin forms when my clients do things like enter product names that contain quotes, often using them to denote inches in their product names. - brian On Mar 15, 2004, at 4:58 PM, Kenneth Grome wrote: >>>> For the sake of discussion, when is it not appropriate to wrap >>>> parameters or user input in [url] tags? >>> >>> In forms you should always put the values inside input contexts, not >>> url contexts. >> >> Well, yes, [input] for displaying textarea values. > > Not just for textarea fields, for regular text fields too. This is a > good standard practice because (for example): > > 1- If you import your db from another source and if any value in any > field *might* have a converted CR character in it, you will need the > input context to keep your form field from 'breaking' if you use > values in that field to populate regular text fields in the form. > > 2- I haven't tested this (or maybe I have and that's why I'm thinking > about it now) but I think it is possible to 'copy and paste' a CR into > a regular text field even though you cannot physsically type a CR into > a text field directly. If this is true, the CR that you 'copied and > pasted' into that field will end up in a database field that you > thought would never contain this kind of character. Thus when you use > this value to populate a text field in a form, that field will break > unless you have put it inside an input context. > > 3- If you use a textarea field for data input and you write that data > to a db, then later you 'change your forms' and decide to use a > regular text field to display the data from this field, the CR's that > were entered while using the textarea field will still be in the db > and therefore you will need to use an input context to populate your > text field with this data to prevent the form from breaking. > > Are there other situations in which a CR might be saved to a db field > without your knowing or expecting it? If so, these would be even more > good reasons to use input in all your form fields that display data, > not just the textarea values. > > -- > > Kenneth Grome > WebDNA Programmer > Outsource Service Provider > Phone: +6332 255-6591 > > ------------------------------------------------------------- > 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/
Brian Fries
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...