numero = 31100
interpreted = N
texte = Please, Please, Please just fix the global tags and leave the hierarchy the way it is. I use a similar technique to Ken's and will have to re-code my more than 40 web sites that rely on Webcatalog if the hierarchy is changed. If we must be weaned off of this hierarchy, please consider a previous post's suggestion of adding a preference to treat all uninitiated variable names as blank. I know that could end up messing up a lot of Javascript code, but I already wrap most of my Javascript in [raw] tags or use js source files anyway.Mike> yes. please to save all that recoding!!! > -John > > Jym Duane wrote: > >> I'm not sure of all the things ken is using the hireachy to do but i know i >> am using >> it as well in similar ways. >> Just fixing certain global variables would make good sense. >> Jym >> >> Kenneth Grome wrote: >> >>>>> Grant do you mean to say that if I have: >>>>> [text]var1=preset[/text] that an incoming form var named var1 will >>>>> *not* override the >>>>> [text]-set value of preset? >>>> >>>> That's right, because people were complaining about a security hole >>>> which allowed you to set [ipaddress] from an incoming form variable, >>>> and lots of people use [ipaddress] to decide if they should show >>>> sensitive information. >>> >>> But [ipaddress] is a global tag, not a variable. Can't you fix this >>> problem (global tags being overridden) without breaking the current >>> variable hierarchy? >>> >>> Maybe you got the parsing code wrong in 3.x when it comes to global >>> tags, but I still think you should leave the variable hierarchy >>> alone. I actually thought you had considered the webcat variable >>> hierarchy long and hard before deciding what it should be, especially >>> since the current variable hierarchy works exceptionally well the way >>> it is. >>> >>> Unfortunately now it seems like you're ready to change it all just >>> because the global tags are being overridden, and this is a *major >>> bummer* to me ... :( >>> >>> Look, here's just one of the many techniques I have developed to save >>> coding time and make my life better when using webdna. I've been >>> doing this ever since text variables were introduced in 3.x as >>> subordinate to formvariables, and it saves me TONS of time ... >>> >>> 1- I put my forms into include files because I use them in several >>> different templates for different purposes, as you will soon see. >>> >>> 2- I always preset my formvariables to blank values by putting code >>> like this at the top of my include file. This first line is useful >>> when presetting text variables to blank values when the form is used >>> to edit a database: >>> >>> [text multi=t][listfields db=xxx.db=[fieldname]=&[/listfields][/text] >>> >>> And this line will reset any specific values to something other than >>> blank if necessary: >>> >>> [text multi=t]city=Honolulu&state=HI[/text] >>> >>> 3- Then I put variable tags in all my form fields to preset their >>> values, like this: >>> >>> >>> >>> >>> >>> >>> >>> When this form is included in an append page, this technique presets >>> the form fields to the values defined by the code in #2 above. >>> >>> When I include the same form in the page that follows an append or >>> replace form, it allows the visitor to edit his entries without >>> having to go Back to do so -- because the formvariables from the >>> previous page *override* the blank presets, thus displaying the >>> values the person just entered on the last page! >>> >>> And when the same form is included in a replace page, all those >>> preset values are overridden by the db fields inside the founditems >>> context. >>> >>> In other words, this technique saves me TONS of time. I rely heavily >>> on the current variable hierarchy that places [text] and [math] >>> variables at the bottom of the hierarchy, and formvariables above >>> them, and db field values above them. It all works exceptionally well >>> just the way it is. >>> > ############################################################# 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 To switch to the INDEX mode, E-mail to Send administrative queries to
Associated Messages, from the most recent to the oldest:
Please, Please, Please just fix the global tags and leave the hierarchy the way it is. I use a similar technique to Ken's and will have to re-code my more than 40 web sites that rely on Webcatalog if the hierarchy is changed. If we must be weaned off of this hierarchy, please consider a previous post's suggestion of adding a preference to treat all uninitiated variable names as blank. I know that could end up messing up a lot of Javascript code, but I already wrap most of my Javascript in [raw] tags or use js source files anyway.Mike> yes. please to save all that recoding!!! > -John > > Jym Duane wrote: > >> I'm not sure of all the things ken is using the hireachy to do but i know i >> am using >> it as well in similar ways. >> Just fixing certain global variables would make good sense. >> Jym >> >> Kenneth Grome wrote: >> >>>>> Grant do you mean to say that if I have: >>>>> [text]var1=preset[/text] that an incoming form var named var1 will >>>>> *not* override the >>>>> [text]-set value of preset? >>>> >>>> That's right, because people were complaining about a security hole >>>> which allowed you to set [ipaddress] from an incoming form variable, >>>> and lots of people use [ipaddress] to decide if they should show >>>> sensitive information. >>> >>> But [ipaddress] is a global tag, not a variable. Can't you fix this >>> problem (global tags being overridden) without breaking the current >>> variable hierarchy? >>> >>> Maybe you got the parsing code wrong in 3.x when it comes to global >>> tags, but I still think you should leave the variable hierarchy >>> alone. I actually thought you had considered the webcat variable >>> hierarchy long and hard before deciding what it should be, especially >>> since the current variable hierarchy works exceptionally well the way >>> it is. >>> >>> Unfortunately now it seems like you're ready to change it all just >>> because the global tags are being overridden, and this is a *major >>> bummer* to me ... :( >>> >>> Look, here's just one of the many techniques I have developed to save >>> coding time and make my life better when using webdna. I've been >>> doing this ever since text variables were introduced in 3.x as >>> subordinate to formvariables, and it saves me TONS of time ... >>> >>> 1- I put my forms into include files because I use them in several >>> different templates for different purposes, as you will soon see. >>> >>> 2- I always preset my formvariables to blank values by putting code >>> like this at the top of my include file. This first line is useful >>> when presetting text variables to blank values when the form is used >>> to edit a database: >>> >>> [text multi=t][listfields db=xxx.db=[fieldname]=&[/listfields][/text] >>> >>> And this line will reset any specific values to something other than >>> blank if necessary: >>> >>> [text multi=t]city=Honolulu&state=HI[/text] >>> >>> 3- Then I put variable tags in all my form fields to preset their >>> values, like this: >>> >>> >>> >>> >>> >>> >>> >>> When this form is included in an append page, this technique presets >>> the form fields to the values defined by the code in #2 above. >>> >>> When I include the same form in the page that follows an append or >>> replace form, it allows the visitor to edit his entries without >>> having to go Back to do so -- because the formvariables from the >>> previous page *override* the blank presets, thus displaying the >>> values the person just entered on the last page! >>> >>> And when the same form is included in a replace page, all those >>> preset values are overridden by the db fields inside the founditems >>> context. >>> >>> In other words, this technique saves me TONS of time. I rely heavily >>> on the current variable hierarchy that places [text] and [math] >>> variables at the bottom of the hierarchy, and formvariables above >>> them, and db field values above them. It all works exceptionally well >>> just the way it is. >>> > ############################################################# 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 To switch to the INDEX mode, E-mail to Send administrative queries to Mike Davis
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...