numero = 61900
interpreted = N
texte = You failed to mention that doing it way also allows you to use the formvariables loop to append/replace in the database too. ----- Original Message ----- From: "Kenneth Grome" To: "WebDNA Talk" Sent: Sunday, May 01, 2005 9:35 PM Subject: Re: SHOWIF/HIDEIF empty fields > 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: > > [showif [url][whatever][/url]=xxx]checked[/showif]> > > [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: >> >> > 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/ ------------------------------------------------------------- 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:
You failed to mention that doing it way also allows you to use the formvariables loop to append/replace in the database too. ----- Original Message ----- From: "Kenneth Grome" To: "WebDNA Talk" Sent: Sunday, May 01, 2005 9:35 PM Subject: Re: SHOWIF/HIDEIF empty fields > 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: > > [showif [url][whatever][/url]=xxx]checked[/showif]> > > [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/ ------------------------------------------------------------- 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/
"WebDna @ Inkblot Media"
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...