[WebDNA] passing a variable in an include - precedence
This WebDNA talk-list message is from 2015
It keeps the original formatting.
numero = 112520
interpreted = N
texte = 88Working on 8.2, we have decided to work on an issue mentioned by =Donovan:> Here is the test page:> http://www.euca.us/admin/tests/include-bug/test.html>=20> The main issue for discussion is that when passing a variable in an =include>=20> [include file=3Dsomefile.inc&var=3Dsomevalue]>=20> You can=E2=80=99t overwrite the var value with a text context =[text]=E2=80=A6[/text] within somefile.inc.>=20> So, if I do>=20> [include file=3Dsomefile.inc&var=3D1]>=20> it is fine. the tag [var] in the included file shows "1">=20> but if I do> [text]var=3D2[/text]> [include file=3Dsomefile.inc&var=3D[var]]>=20> then the tag [var] in the included file shows "[var]" instead of "2"This isn't a simple problem, it goes pretty deep into how WebDNA =retrieves variables.The order of precedence for variable lookups is:1.) [INCLUDE] cgi parameters2.) text variables3.) math variables4.) regular cgi parameters (passed via URL or POST)These variables are all kept in separate variable lists, and there is =normally no checking between lists. So you can have a text and a CGI =variable with the same name at the same time.Normally, WebDNA is taking advantage of the fact that regular CGI =parameters are going to be the earliest assignment of any variable, so =they can be treated with lowest priority and it will work correctly. =However, when you do an include, we need to create a new set of CGI =parameters that are treated as highest priority inside of a new context. =This creates all sorts of problems with getting the order of precedence =correct.We decided the best solution is to make all assignments of text =variables delete similarly named CGI parameters in all [INCLUDE] =contexts. This makes it work correctly even if you include a file inside =of another include.[math] variable assignments though will still be ignored if there is a =conflicting variable passed via an include.[math] variables are already treated as inferior. For example, this code =returns Var=3D4:[text]var=3D4[/text][math]var=3D1[/math]Var=3D[var]With 8.2, Donovan test shows this output now:Value of VAR from first include: 1Value of VAR after setting it in first include: 2Value of VAR from second include: 2---------------------------------------------------------This message is sent to you because you are subscribed tothe mailing list
.To unsubscribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.usBug Reporting: support@webdna.us.
Associated Messages, from the most recent to the oldest:
88Working on 8.2, we have decided to work on an issue mentioned by =Donovan:> Here is the test page:> http://www.euca.us/admin/tests/include-bug/test.html>=20> The main issue for discussion is that when passing a variable in an =include>=20> [include file=3Dsomefile.inc&var=3Dsomevalue]>=20> You can=E2=80=99t overwrite the var value with a text context =[text]=E2=80=A6[/text] within somefile.inc.>=20> So, if I do>=20> [include file=3Dsomefile.inc&var=3D1]>=20> it is fine. the tag [var] in the included file shows "1">=20> but if I do> [text]var=3D2[/text]> [include file=3Dsomefile.inc&var=3D[var]]>=20> then the tag [var] in the included file shows "[var]" instead of "2"This isn't a simple problem, it goes pretty deep into how WebDNA =retrieves variables.The order of precedence for variable lookups is:1.) [include] cgi parameters2.) text variables3.) math variables4.) regular cgi parameters (passed via URL or POST)These variables are all kept in separate variable lists, and there is =normally no checking between lists. So you can have a text and a CGI =variable with the same name at the same time.Normally, WebDNA is taking advantage of the fact that regular CGI =parameters are going to be the earliest assignment of any variable, so =they can be treated with lowest priority and it will work correctly. =However, when you do an include, we need to create a new set of CGI =parameters that are treated as highest priority inside of a new context. =This creates all sorts of problems with getting the order of precedence =correct.We decided the best solution is to make all assignments of text =variables delete similarly named CGI parameters in all [include] =contexts. This makes it work correctly even if you include a file inside =of another include.[math] variable assignments though will still be ignored if there is a =conflicting variable passed via an include.[math] variables are already treated as inferior. For example, this code =returns Var=3D4:[text]var=3D4[/text][math]var=3D1[/math]Var=3D[var]With 8.2, Donovan test shows this output now:Value of VAR from first include: 1Value of VAR after setting it in first include: 2Value of VAR from second include: 2---------------------------------------------------------This message is sent to you because you are subscribed tothe mailing list .To unsubscribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.usBug Reporting: support@webdna.us.
christophe.billiottet@webdna.us
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:
WebCatalog for guestbook ? (1997)
WebCat2_Mac RETURNs in .db (1997)
Big Databases (1997)
Progress !! WAS: Trouble with formula.db (1997)
Only charge card when product shipped ? (1997)
repost: I'd like the image this chunk of WEBDNA returns to be hyperlinked to the (2000)
How to Sort Summ data ? (1997)
Converting SQL Microtime to Date and Time (2003)
WebCat2b13MacPlugIn - [showif][search][/showif] (1997)
Searchable WebCat (etc.) Docs ? (1997)
Summing fields (1997)
unable to launch acgi in WebCat (1997)
Re:Virtual hosting and webcatNT (1997)
Autonumber (2003)
New Business Opportunity (2006)
Emailer setup (1997)
OUTSIDE LINKS TO SHOW SHOPPING CART????????? (1998)
[WebDNA] WebDNA 8.6.4 (2020)
Verifying both name and password (was: New Problem) (1997)
email error 159 (1998)