Re: [WebDNA] passing a variable in an include - precedence
This WebDNA talk-list message is from 2015
It keeps the original formatting.
numero = 112523
interpreted = N
texte = 91 Okay, one email on this.... have to hit a new website deadline today. In my opinion there *is* something wrong with the way it works now. The include file has an existing *feature* that allows setting = variables=85. and it=92s wonky / broken because it doesn=92t work like = other methods that we have in place for setting variables (ie. [text = scope=3Dglobal]; and yes Matthew, we are not clear on what the scoping = of said variable is. Whether =93you" use this syntax or not, it is there, and it is wonky.=20 If everyone prefers to use Ken's solution: [text]var=3Dsomevalue[/text] [include somefile.inc] [text]var=3D[raw][var][/raw][/text] Over a more standardized solution: [include somefile.inc&var=3Dsomevalue] And if you don=92t care that the feature of setting variables within = include is broken, And if you don=92t care about scoping in WebDNA, then = maybe there is nothing to be concerned about here.=20 I had to remind myself why I took the time to bring this up in the first = place. It has to do with contemporary programming techniques. WebDNA is = not likely to ever be an OOP language, but certainly some of the core = principles behind it are important=85 such as code reuse and = encapsulation.=20 [include] was made for code reuse of course, and yes, it does allow the = setting of variables.=20 One of the last things SMSI did when working on the engine was to = introduce variable scoping. It was an effort to bring WebDNA into the = realm of a more sophisticated / contemporary language=85 with the use of = [function], [scope] ([::var], [:named-name:var] etc.. (encapsulation) It is clear to me that it is not finished / refined, and yes Matthew, it = certainly could use looking into and the docs generated / defined = better.=20 In my opinion, fixing the syntax here allows for much more standardized = use of these contemporary techniques that SMSI introduced, and that have = not been refined / clarified.=20 I use it all the time=85 which is probably why I ran into the bug. [include file=3Dincludes/BodyCall.inc&D=3Dsome1.inc&R=3Dsome2.inc] In my original test template, I went ahead and did some quick tests. I = tried changing the variable to different scopes in the first include: ----- main page: [include file=3Dsome.inc&var=3D1] some.inc: [text scope=3Dsecure]var=3D2[/text] [!] ** tried many scope names ** [include file=3Dsome2.inc] =97=97 I also tried implicitly setting the scope: =97=97 main page: [scope name=3Dsomescope] [include file=3Dsome.inc&var=3D1] [/scope] some.inc [text scope=3Dsomescope]var=3D2[/text] [include file=3Dsome2.inc] =97=97 Basically, I thought maybe =93&var=3D1=94 was being set to a certain = scope that I could =93find".. but I could not find it. All [var] values = are =911=92. I then decided to try the PHP way by making use of function: PHP: function includeF($someVar) { include ("inc/header.php"); } WebDNA: =97=97 main page: [function name=3Dstartinclude] [include file=3Dsome.inc] [/function] [startinclude var=3D1] some.inc: [text scope=3Dstartinclude]var=3D2[/text] [include file=3Dsome2.inc] =97=97 The above did not work.. I used to think that [function]=92s have their = own scope defined by their variable name (=93startinclude=94 in this = case), but I now don=92t think that is the case, though I didn=92t test = thoroughy This *DID* work as a workaround: =97=97 main page: [function name=3Dstartinclude] [include file=3Dsome.inc] [/function] [startinclude var=3D1] some.inc: [text scope=3Dglobal]var=3D2[/text] [include file=3Dsome2.inc] =97=97 See it here: http://www.euca.us/admin/tests/include-bug2/test.html (note the use '[:named-global:var]=92 in that link) I also tried setting the scope explicitly with my own naming, in the = [function] solution=85 but that did NOT work.=20 Anyway, here is my thoughts on the subject. I do agree with Matthew that a clear set of Docs are needed on scoping = priorities.. but Ultimately, a **PROGRAMMING CLARITY** is needed first = on=20 how to deal with these =93contemporary=94 (I use this term lightly, = because this is something other languages have been incorporating years = ago) features in WebDNA. How does WebDNA want to refine scoping and the use of the [function] = context that SMSI started in 2004? That is the real question that will = either move WebDNA forward, or keep it in a confusing 2004 era. Also ultimately, this little issue of setting a var in an include tag = brings up a complicated subject that could involve a complicated = solution=85 maybe WebDNA wants to remain a non-complicated language.... = For you to decided. :-) For now, if WSC wanted to keep a fix as simple as possible, I=92d = suggest looking into these three things: 1.) Allocating the variable setting from [include] to the global = namespace by default. So, by default, you should be able to change that = variable, thus fixing my original problem. (may be more complicated than = that ;-) ) 2.) Being able to implicitly scope the [include] tag, or at least the = variables it can set, something like: [INCLUDE file=3DFilePath&scope=3Dthescopename&var=3D1] That might further the efforts to address the dissimilarities of setting = vars in that tag, vs.. our other methods.=20 =46rom there, you should be able to tie into that space with the regular = scoping features of WebDNA, for example [:named-thescopename:var] 3.) Checking into the scoping space with the use of the [function] = context. As I mentioned, I thought the function had it=92s own scope = defined by the function name itself, but it appears not. The main idea though is to be able to explicitly name variable scope, then get to = them using our normal methods. scope=3Dglobal works, but it appears not = any other naming works. Maybe this is just a problem of the =91scope=3D=91= param.. not sure. Here is a page on this: http://www.euca.us/admin/tests/scope.html Anyway, I had brought this up for =93discussion=94 because it is was = wonky feature in WebDNA.. that may open a complicated topic=85 It is an issue that probably only pertains to developers doing more = sophisticated programming.=20 Have a peachy Sunday, Donovan Here is my original text by the way: =97=97=97 Hello, This is meant to spark some discussion.. a bit technical question of = whether the include tag should be changed slightly. Here is my test page: http://www.euca.us/admin/tests/include-bug/test.html The main issue for discussion is that when passing a variable in an = include: [include file=3Dsomefile.inc&var=3Dsomevalue] You can=92t overwrite the var value with a text context within = somefile.inc.=20 (I am guessing it is in a scope-preferred assignment... but haven=92t = looked that deeply yet... maybe this is documented somewhere=85 I don=92t = know.) Moreso, For me, i=92m wondering if it would be more intuitive if that = var only acted within the scope of that include file (level) only. For example in my test, there is an inc2.inc. Lets assume that in = inc1.inc that I don=92t actually try to reset var with 2. In that case, = it might be good if the value of var (within inc2.inc) is literally =91[var]=92, = (un-initialized). This question addresses encapsulation for the [include] tag I guess=85 = would we want it, or would we not=85 what are the ramifications, etc..=20= In my test, if we made the encapsulation change, the value of var within = inc2.inc would be =912=92, because I had set the text var above in the = hierarchy.=20 So, two questions regarding the old [include] tag for discussion: 1.) Why can=92t or shouldn't a text var be able to override a passed = variable? 2.) What about the idea of encapsulation for the passed variables? ------ On Nov 21, 2015, at 7:59 AM, Kenneth Grome
= wrote: >>> The main issue for discussion is that when passing a variable >>> in an include >>>=20 >>> [include file=3Dsomefile.inc&var=3Dsomevalue] >>>=20 >>> You can=92t overwrite the var value with a text context >>> [text]=85[/text] within somefile.inc. >=20 >=20 > This is not a big deal. There is nothing wrong with the way it > works now. You can easily set the var value before the include > tag like I always do, then you can override it inside the include > file all you want: >=20 > [text]var=3Dsomevalue[/text] > [include somefile.inc] >=20 > And if for some reason it "bothers you" that [var] will have a > value below the include tag, just undo it like this: >=20 > [text]var=3Dsomevalue[/text] > [include somefile.inc] > [text]var=3D[raw][var][/raw][/text] >=20 > Regards, > Kenneth Grome > WebDNA Solutions > http://www.webdnasolutions.com > Web Database Systems and Linux Server Administration >=20 >=20 > --------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > archives: http://mail.webdna.us/list/talk@webdna.us > Bug Reporting: support@webdna.us --------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.us Bug Reporting: support@webdna.us .
Associated Messages, from the most recent to the oldest:
91 Okay, one email on this.... have to hit a new website deadline today. In my opinion there *is* something wrong with the way it works now. The include file has an existing *feature* that allows setting = variables=85. and it=92s wonky / broken because it doesn=92t work like = other methods that we have in place for setting variables (ie. [text = scope=3Dglobal]; and yes Matthew, we are not clear on what the scoping = of said variable is. Whether =93you" use this syntax or not, it is there, and it is wonky.=20 If everyone prefers to use Ken's solution: [text]var=3Dsomevalue[/text] [include somefile.inc] [text]var=3D[raw][var][/raw][/text] Over a more standardized solution: [include somefile.inc&var=3Dsomevalue] And if you don=92t care that the feature of setting variables within = include is broken, And if you don=92t care about scoping in WebDNA, then = maybe there is nothing to be concerned about here.=20 I had to remind myself why I took the time to bring this up in the first = place. It has to do with contemporary programming techniques. WebDNA is = not likely to ever be an OOP language, but certainly some of the core = principles behind it are important=85 such as code reuse and = encapsulation.=20 [include] was made for code reuse of course, and yes, it does allow the = setting of variables.=20 One of the last things SMSI did when working on the engine was to = introduce variable scoping. It was an effort to bring WebDNA into the = realm of a more sophisticated / contemporary language=85 with the use of = [function], [scope] ([::var], [:named-name:var] etc.. (encapsulation) It is clear to me that it is not finished / refined, and yes Matthew, it = certainly could use looking into and the docs generated / defined = better.=20 In my opinion, fixing the syntax here allows for much more standardized = use of these contemporary techniques that SMSI introduced, and that have = not been refined / clarified.=20 I use it all the time=85 which is probably why I ran into the bug. [include file=3Dincludes/BodyCall.inc&D=3Dsome1.inc&R=3Dsome2.inc] In my original test template, I went ahead and did some quick tests. I = tried changing the variable to different scopes in the first include: ----- main page: [include file=3Dsome.inc&var=3D1] some.inc: [text scope=3Dsecure]var=3D2[/text] [!] ** tried many scope names ** [include file=3Dsome2.inc] =97=97 I also tried implicitly setting the scope: =97=97 main page: [scope name=3Dsomescope] [include file=3Dsome.inc&var=3D1] [/scope] some.inc [text scope=3Dsomescope]var=3D2[/text] [include file=3Dsome2.inc] =97=97 Basically, I thought maybe =93&var=3D1=94 was being set to a certain = scope that I could =93find".. but I could not find it. All [var] values = are =911=92. I then decided to try the PHP way by making use of function: PHP: function includeF($someVar) { include ("inc/header.php"); } WebDNA: =97=97 main page: [function name=3Dstartinclude] [include file=3Dsome.inc] [/function] [startinclude var=3D1] some.inc: [text scope=3Dstartinclude]var=3D2[/text] [include file=3Dsome2.inc] =97=97 The above did not work.. I used to think that [function]=92s have their = own scope defined by their variable name (=93startinclude=94 in this = case), but I now don=92t think that is the case, though I didn=92t test = thoroughy This *DID* work as a workaround: =97=97 main page: [function name=3Dstartinclude] [include file=3Dsome.inc] [/function] [startinclude var=3D1] some.inc: [text scope=3Dglobal]var=3D2[/text] [include file=3Dsome2.inc] =97=97 See it here: http://www.euca.us/admin/tests/include-bug2/test.html (note the use '[:named-global:var]=92 in that link) I also tried setting the scope explicitly with my own naming, in the = [function] solution=85 but that did NOT work.=20 Anyway, here is my thoughts on the subject. I do agree with Matthew that a clear set of Docs are needed on scoping = priorities.. but Ultimately, a **PROGRAMMING CLARITY** is needed first = on=20 how to deal with these =93contemporary=94 (I use this term lightly, = because this is something other languages have been incorporating years = ago) features in WebDNA. How does WebDNA want to refine scoping and the use of the [function] = context that SMSI started in 2004? That is the real question that will = either move WebDNA forward, or keep it in a confusing 2004 era. Also ultimately, this little issue of setting a var in an include tag = brings up a complicated subject that could involve a complicated = solution=85 maybe WebDNA wants to remain a non-complicated language.... = For you to decided. :-) For now, if WSC wanted to keep a fix as simple as possible, I=92d = suggest looking into these three things: 1.) Allocating the variable setting from [include] to the global = namespace by default. So, by default, you should be able to change that = variable, thus fixing my original problem. (may be more complicated than = that ;-) ) 2.) Being able to implicitly scope the [include] tag, or at least the = variables it can set, something like: [INCLUDE file=3DFilePath&scope=3Dthescopename&var=3D1] That might further the efforts to address the dissimilarities of setting = vars in that tag, vs.. our other methods.=20 =46rom there, you should be able to tie into that space with the regular = scoping features of WebDNA, for example [:named-thescopename:var] 3.) Checking into the scoping space with the use of the [function] = context. As I mentioned, I thought the function had it=92s own scope = defined by the function name itself, but it appears not. The main idea though is to be able to explicitly name variable scope, then get to = them using our normal methods. scope=3Dglobal works, but it appears not = any other naming works. Maybe this is just a problem of the =91scope=3D=91= param.. not sure. Here is a page on this: http://www.euca.us/admin/tests/scope.html Anyway, I had brought this up for =93discussion=94 because it is was = wonky feature in WebDNA.. that may open a complicated topic=85 It is an issue that probably only pertains to developers doing more = sophisticated programming.=20 Have a peachy Sunday, Donovan Here is my original text by the way: =97=97=97 Hello, This is meant to spark some discussion.. a bit technical question of = whether the include tag should be changed slightly. Here is my test page: http://www.euca.us/admin/tests/include-bug/test.html The main issue for discussion is that when passing a variable in an = include: [include file=3Dsomefile.inc&var=3Dsomevalue] You can=92t overwrite the var value with a text context within = somefile.inc.=20 (I am guessing it is in a scope-preferred assignment... but haven=92t = looked that deeply yet... maybe this is documented somewhere=85 I don=92t = know.) Moreso, For me, i=92m wondering if it would be more intuitive if that = var only acted within the scope of that include file (level) only. For example in my test, there is an inc2.inc. Lets assume that in = inc1.inc that I don=92t actually try to reset var with 2. In that case, = it might be good if the value of var (within inc2.inc) is literally =91[var]=92, = (un-initialized). This question addresses encapsulation for the [include] tag I guess=85 = would we want it, or would we not=85 what are the ramifications, etc..=20= In my test, if we made the encapsulation change, the value of var within = inc2.inc would be =912=92, because I had set the text var above in the = hierarchy.=20 So, two questions regarding the old [include] tag for discussion: 1.) Why can=92t or shouldn't a text var be able to override a passed = variable? 2.) What about the idea of encapsulation for the passed variables? ------ On Nov 21, 2015, at 7:59 AM, Kenneth Grome = wrote: >>> The main issue for discussion is that when passing a variable >>> in an include >>>=20 >>> [include file=3Dsomefile.inc&var=3Dsomevalue] >>>=20 >>> You can=92t overwrite the var value with a text context >>> [text]=85[/text] within somefile.inc. >=20 >=20 > This is not a big deal. There is nothing wrong with the way it > works now. You can easily set the var value before the include > tag like I always do, then you can override it inside the include > file all you want: >=20 > [text]var=3Dsomevalue[/text] > [include somefile.inc] >=20 > And if for some reason it "bothers you" that [var] will have a > value below the include tag, just undo it like this: >=20 > [text]var=3Dsomevalue[/text] > [include somefile.inc] > [text]var=3D[raw][var][/raw][/text] >=20 > Regards, > Kenneth Grome > WebDNA Solutions > http://www.webdnasolutions.com > Web Database Systems and Linux Server Administration >=20 >=20 > --------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > archives: http://mail.webdna.us/list/talk@webdna.us > Bug Reporting: support@webdna.us --------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.us Bug Reporting: support@webdna.us .
Donovan Brooke
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:
Summing fields (1997)
Ok here is a question? (1997)
ThreadMem ignored? (1998)
credit card question (simple) (2001)
[SearchString] problem with [search] context (1997)
Hiding a subsection of text (2002)
POSTing to a secure server ... (2000)
RE: [WebDNA] FindString - source: multiple words (2019)
Purchase Plugin Missing (1996)
snicker, snicker (1997)
Date math (1997)
[OT] Connect to MySQL (2004)
Cold Fusion Buster (1997)
back button loses cart (2000)
target=_blank and form variables (1997)
RE: Help name our technology! (1997)
WebCat2b13MacPlugin - nested [xxx] contexts (1997)
date (1999)
The EMailer and the Blank menu bar? (1999)
BGcolor (1997)