Proposed FormVariables hierarchy
This WebDNA talk-list message is from 2000
It keeps the original formatting.
numero = 31579
interpreted = N
texte = Under 3.x the implied hierarchy of values is the following:Application Context (things like [VERSION] [DATE] [TIME] [ELAPSEDTIME], all text vars) Browser Context (things like [IPADDRESS] [REFERRER] [USERNAME] [PASSWORD]) HTML Form Context (all passed-in form variables, smart [CART]) template code (your own contexts nested however you decide) [xxx] <- look for xxx here, and if not found, go up ^^^Whenever a tag is being evaluated, the parser starts locally and looks outward (or upward, if you prefer) for values. You can see from this hierarchy that form variables are found first, before browser variables or application variables.Under 4.0 beta, the implied hierarchy is the following:HTML Form Context (all passed-in form variables, smart [CART]) Application Context (things like [VERSION] [DATE] [TIME] [ELAPSEDTIME], all text vars) Browser Context (things like [IPADDRESS] [REFERRER] [USERNAME] [PASSWORD]) template code (your own contexts nested however you decide) [xxx] <- look for xxx here, and if not found, go up ^^^In this hierarchy, [ipaddress] is found first, then [text] vars, and finally passed-in form variables. This provides for the much-requested feature that prevents any passed-in form variables from changing the values of internal variables like [ipaddress]. It also provides for the much-requested feature of being able to override the value of [cart] with a text variable of the same name.A proposed new hierarchy might go something like this:HTML Form Context (all passed-in form variables, smart [CART], insecure text vars) Application Context (things like [VERSION] [DATE] [TIME] [ELAPSEDTIME], default secure text vars) Browser Context (things like [IPADDRESS] [REFERRER] [USERNAME] [PASSWORD]) template code (your own contexts nested however you decide) [xxx] <- look for xxx here, and if not found, go up ^^^By adding a second namespace for holding text variables (up in the HTML Form Context), we can provide a place for storing insecure text variables. The parser will find secure text variables first, then form variables, then insecure textvariables. A side-effect would be that one could have text variables with exactly the same name in both namespaces, but secure ones would be found first.Default behavior would be to store text variables in the secure namespace. Adding the optional secure=F parameter like [text secure=f]fred=hello[/text] would put those values into the new un-secure namespace.Grant Hulbert, Director of Engineering ********************************** Smith Micro, Internet Solutions Div | eCommerce (WebCatalog) 16855 West Bernardo Drive, #380 | ------------------------- San Diego, CA 92127 | Software & Site Development Main Line: (858) 675-1106 | http://www.smithmicro.com Fax: (858) 675-0372 **********************************############################################################# 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:
Under 3.x the implied hierarchy of values is the following:Application Context (things like [version] [date] [time] [elapsedtime], all text vars) Browser Context (things like [ipaddress] [referrer] [username] [password]) HTML Form Context (all passed-in form variables, smart [cart]) template code (your own contexts nested however you decide) [xxx] <- look for xxx here, and if not found, go up ^^^Whenever a tag is being evaluated, the parser starts locally and looks outward (or upward, if you prefer) for values. You can see from this hierarchy that form variables are found first, before browser variables or application variables.Under 4.0 beta, the implied hierarchy is the following:HTML Form Context (all passed-in form variables, smart [cart]) Application Context (things like [version] [date] [time] [elapsedtime], all text vars) Browser Context (things like [ipaddress] [referrer] [username] [password]) template code (your own contexts nested however you decide) [xxx] <- look for xxx here, and if not found, go up ^^^In this hierarchy, [ipaddress] is found first, then [text] vars, and finally passed-in form variables. This provides for the much-requested feature that prevents any passed-in form variables from changing the values of internal variables like [ipaddress]. It also provides for the much-requested feature of being able to override the value of [cart] with a text variable of the same name.A proposed new hierarchy might go something like this:HTML Form Context (all passed-in form variables, smart [cart], insecure text vars) Application Context (things like [version] [date] [time] [elapsedtime], default secure text vars) Browser Context (things like [ipaddress] [referrer] [username] [password]) template code (your own contexts nested however you decide) [xxx] <- look for xxx here, and if not found, go up ^^^By adding a second namespace for holding text variables (up in the HTML Form Context), we can provide a place for storing insecure text variables. The parser will find secure text variables first, then form variables, then insecure textvariables. A side-effect would be that one could have text variables with exactly the same name in both namespaces, but secure ones would be found first.Default behavior would be to store text variables in the secure namespace. Adding the optional secure=F parameter like [text secure=f]fred=hello[/text] would put those values into the new un-secure namespace.Grant Hulbert, Director of Engineering ********************************** Smith Micro, Internet Solutions Div | eCommerce (WebCatalog) 16855 West Bernardo Drive, #380 | ------------------------- San Diego, CA 92127 | Software & Site Development Main Line: (858) 675-1106 | http://www.smithmicro.com Fax: (858) 675-0372 **********************************############################################################# 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
GHulbert@smithmicro.com
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
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...
Related Readings:
How about the Pascal approach? (2004)
WC2b15 File Corruption (1997)
Country & Ship-to address & other fields ? (1997)
WC1.6 to WC2 date formatting (1997)
WebCat2b15MacPlugIn - [authenticate] not [protect] (1997)
Malformed Pages (1999)
2.0Beta Command Ref (can't find this instruction) (1997)
Add to Cart & List of Products (1997)
[SHOWIF AND/OR] (1997)
Quickie question on the email templates (1997)
RE: New WebCatalog Version !!! (1997)
Where is the bug fix info for 4.0.1? (2000)
WebMerchant and Mac Auth Hub Help Please (1999)
Document Contains No Data! (1997)
Frames and WebCat (1997)
WebCatalog 3.0.4 alias crash bug? (2000)
WebDNA-Talk Digest mode broken (1997)
Did you hear about this? (1997)
[WebDNA] help with [ReturnRaw] - why is it killing the parse of the [include] file? (2009)
WebTV (1998)