numero = 31083
interpreted = N
texte = >>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. ================================ Kenneth Grome, WebDNA Consultant 808-737-6499 http://webdna.net ================================############################################################# 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:
>>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. ================================ Kenneth Grome, WebDNA Consultant 808-737-6499 http://webdna.net ================================############################################################# 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 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...