numero = 31093
interpreted = N
texte = yes. please to save all that recoding!!! -JohnJym 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:
yes. please to save all that recoding!!! -JohnJym 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 John Butler
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...