numero = 61899
interpreted = N
texte = Hi Gary, I'm going to show you a simple technique to eliminate most of the "pain-in-the-ass" coding you've been dealing with. First you should know that I always name my form fields with the exact same names as the fields in my database, because this simplifies TONS of webdna coding -- not just the stuff I will show you here. After you understand this requirement, you will also see how and why my technique works so well. First I create a bunch of insecure text variables and set their values to [blank] like this: [listfields db=xxx.db] [text secure=f][fieldname]=[/text] [/listfields] Of course if I didn't give my form fields and db fields the same names, this technique would not be available to me, and instead I would have to create all these variables manually -- so it's a good thing that I name my form fields exactly the same as my database fields ... :) This code goes ABOVE the form you're trying to populate. The only purpose of this code is to force the form to display [blank] values in the fields that do not have corresponding formvariables passed in from the previous page. If I didn't use this technique to preset all these variables to blank values, the ones not passed as formvariables from the previous page would display the raw webdna field name tags -- and this simple technique eliminates that little problem ... :) Then just use this code to populate each field in your form: ... or use a simple variation of this code for fields other than text fields: .... and that's all there is to it! When you use this technique properly as I have described it, the [whatever] tag will be set to a [blank] value by the insecure text variable UNLESS a corresponding formvariable with the name "whatever" is passed to the page -- in which case the [whatever] formvariable value will populate the field instead of the blank value. This is the "easy way" (or what I consider to be the most efficient way) to avoid using all those [raw] contexts, and it has worked very reliably for me ever since text variables were first introduced about 5 years ago ... :) Sincerely, Kenneth Grome www.kengrome.com P.S. My $10 per hour Filipino webdna programmers use this technique consistently, as they have from day one -- because I trained them personally -- and I demand that they perform as efficiently in their work as I do. We use all kinds of techniques like this to be extremely efficient with our programming time, so it's not just the $10 per hour price that's a bargain, it is also the quality of the code you get from us that makes our service worthwhile. Just something to keep in mind for the future when you have more programming work than you can handle ... or when you'd rather pay someone $10 an hour to do your work for you, so you can go out and have fun instead ... :) On May 2, 2005, at 10:52, Gary Krockover wrote: > Hi Ken, > > Correct, my mistake - it's not the landing page on forms but when > recalling a pre-populated form, such as in the case where the visitor > missed a required field and I've redirected them back to the form > while checking for existing values in a custom "required fields" > situation. > > Example, visitor fills in form, that appends to a db but they missed a > field. I redirect them back to the form and repopulate the form from > what they did fill in. One of the fields: > > maxlength="3"> > > That just seems to be too much. But yes, I've tried the > [url][field][/url]=] route, and it wont catch it if the field equals > [field]. Example: > > > > [showif [didsubmit]=T] > [text show=f]thefield=[raw][thefield][/raw][/text] > > [showif [url][thefield][/url]=]It equals nothing[/showif] > > [showif [thefield]=[raw][thefield][/raw]]It equals the field > name[/showif] > > [showif =[thefield]] > ... this is shown when [fieldname] is blank ... > [/showif] > [/showif] > > Now, this is probably an error with my coding on the original form. I > could (should?) on the append, check to see if a field was populated > and if not then zero it out fully, but I'm still checking to see if it > equals [raw][field][/raw], either there or when repopulating the form. > > But ugh, it's too late on a Sunday night to worry with this now. :) > > GJK > > > At 08:40 PM 5/1/2005, you wrote: >> I wonder why you're not avoiding the use of raw contexts by using >> this technique instead: >> >> [showif [url][field][/url]=] >> ... this is shown when [fieldname] is blank ... >> [/showif] >> >> Of course you should be [url]ing your [field] value as in this >> example -- to prevent any comparison operators from screwing up your >> showif comparisons. By the way, when I know that the visitor >> cannot enter an ending webdna bracket (which would become part of the >> [field] value) I sometimes use this technique because it's even more >> efficient: >> >> [showif =[field]] >> ... this is shown when [fieldname] is blank ... >> [/showif] >> >> This works when the the [field] value does NOT have an ending bracket >> in it, such as in fields that are not editable by the visitor -- >> hidden, radio, checkbox and select -- assuming you do not put the >> ending bracket in one of these field values yourself! >> >> The bottom line is that I haven't used raw contexts for this purpose >> in years ... not that it doesn't work but it seems there are more >> efficient coding techniques to use in this case. >> >> But I actually think you've confused the place where you're using >> [raw] contexts anyways. Aren't you actually using them in your edit >> forms, and not on the pages that follow your form submissions? The >> reason I ask is because the [field] values in the page after the form >> submission are always going to have values, even if they are [blank] >> values. >> >> In other words, putting a [fieldname] tag on this page is never going >> to result in the raw [field] tag being displayed because that form >> field will always have a value that's set in the form, even if that >> value is blank -- unless it's a checkbox field that was not checked >> of course, because that's the only HTML form that does NOT get passed >> as a name-value pair in a form submission. >> >> Sincerely, >> Kenneth Grome >> www.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/ > > ------------------------------------------------------------- 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:
Hi Gary, I'm going to show you a simple technique to eliminate most of the "pain-in-the-ass" coding you've been dealing with. First you should know that I always name my form fields with the exact same names as the fields in my database, because this simplifies TONS of webdna coding -- not just the stuff I will show you here. After you understand this requirement, you will also see how and why my technique works so well. First I create a bunch of insecure text variables and set their values to [blank] like this: [listfields db=xxx.db] [text secure=f][fieldname]=[/text] [/listfields] Of course if I didn't give my form fields and db fields the same names, this technique would not be available to me, and instead I would have to create all these variables manually -- so it's a good thing that I name my form fields exactly the same as my database fields ... :) This code goes ABOVE the form you're trying to populate. The only purpose of this code is to force the form to display [blank] values in the fields that do not have corresponding formvariables passed in from the previous page. If I didn't use this technique to preset all these variables to blank values, the ones not passed as formvariables from the previous page would display the raw webdna field name tags -- and this simple technique eliminates that little problem ... :) Then just use this code to populate each field in your form: [input][whatever][/input]"> ... or use a simple variation of this code for fields other than text fields: [url][whatever][/url]=xxx]checked[/showif]> [url][whatever][/url]=yyy]checked[/showif]> .... and that's all there is to it! When you use this technique properly as I have described it, the [whatever] tag will be set to a [blank] value by the insecure text variable UNLESS a corresponding formvariable with the name "whatever" is passed to the page -- in which case the [whatever] formvariable value will populate the field instead of the blank value. This is the "easy way" (or what I consider to be the most efficient way) to avoid using all those [raw] contexts, and it has worked very reliably for me ever since text variables were first introduced about 5 years ago ... :) Sincerely, Kenneth Grome www.kengrome.com P.S. My $10 per hour Filipino webdna programmers use this technique consistently, as they have from day one -- because I trained them personally -- and I demand that they perform as efficiently in their work as I do. We use all kinds of techniques like this to be extremely efficient with our programming time, so it's not just the $10 per hour price that's a bargain, it is also the quality of the code you get from us that makes our service worthwhile. Just something to keep in mind for the future when you have more programming work than you can handle ... or when you'd rather pay someone $10 an hour to do your work for you, so you can go out and have fun instead ... :) On May 2, 2005, at 10:52, Gary Krockover wrote: > Hi Ken, > > Correct, my mistake - it's not the landing page on forms but when > recalling a pre-populated form, such as in the case where the visitor > missed a required field and I've redirected them back to the form > while checking for existing values in a custom "required fields" > situation. > > Example, visitor fills in form, that appends to a db but they missed a > field. I redirect them back to the form and repopulate the form from > what they did fill in. One of the fields: > > [input][showif > [CVV2]!][showif > [CVV2]![raw][CVV2][/raw]][CVV2][/showif][/showif][/input]" size="5" > maxlength="3"> > > That just seems to be too much. But yes, I've tried the > [url][field][/url]=] route, and it wont catch it if the field equals > [field]. Example: > > > > [showif [didsubmit]=T] > [text show=f]thefield=[raw][thefield][/raw][/text] > > [showif [url][thefield][/url]=]It equals nothing[/showif] > > [showif [thefield]=[raw][thefield][/raw]]It equals the field > name[/showif] > > [showif =[thefield]] > ... this is shown when [fieldname] is blank ... > [/showif] > [/showif] > > Now, this is probably an error with my coding on the original form. I > could (should?) on the append, check to see if a field was populated > and if not then zero it out fully, but I'm still checking to see if it > equals [raw][field][/raw], either there or when repopulating the form. > > But ugh, it's too late on a Sunday night to worry with this now. :) > > GJK > > > At 08:40 PM 5/1/2005, you wrote: >> I wonder why you're not avoiding the use of raw contexts by using >> this technique instead: >> >> [showif [url][field][/url]=] >> ... this is shown when [fieldname] is blank ... >> [/showif] >> >> Of course you should be [url]ing your [field] value as in this >> example -- to prevent any comparison operators from screwing up your >> showif comparisons. By the way, when I know that the visitor >> cannot enter an ending webdna bracket (which would become part of the >> [field] value) I sometimes use this technique because it's even more >> efficient: >> >> [showif =[field]] >> ... this is shown when [fieldname] is blank ... >> [/showif] >> >> This works when the the [field] value does NOT have an ending bracket >> in it, such as in fields that are not editable by the visitor -- >> hidden, radio, checkbox and select -- assuming you do not put the >> ending bracket in one of these field values yourself! >> >> The bottom line is that I haven't used raw contexts for this purpose >> in years ... not that it doesn't work but it seems there are more >> efficient coding techniques to use in this case. >> >> But I actually think you've confused the place where you're using >> [raw] contexts anyways. Aren't you actually using them in your edit >> forms, and not on the pages that follow your form submissions? The >> reason I ask is because the [field] values in the page after the form >> submission are always going to have values, even if they are [blank] >> values. >> >> In other words, putting a [fieldname] tag on this page is never going >> to result in the raw [field] tag being displayed because that form >> field will always have a value that's set in the form, even if that >> value is blank -- unless it's a checkbox field that was not checked >> of course, because that's the only HTML form that does NOT get passed >> as a name-value pair in a form submission. >> >> Sincerely, >> Kenneth Grome >> www.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/ > > ------------------------------------------------------------- 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
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...