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:
[BULK] [WebDNA] [if] or [case] or something else (2012)
unitshipcost vs shipcosts (1997)
Multiple Pulldowns (1997)
wierd [cart] action! (1997)
Re:Help name our technology! (1997)
Kanji in http requests (1998)
dates as search criteria (2000)
Help! WebCat2 bug (1997)
Moment of Thanks (1997)
Lambada for Macintosh is Here! (1996)
emailer (1997)
Sorting error (1997)
[WebDNA] slideshow (2008)
help with duplicate records posted (1998)
Smart caching problems with 2.1b3? (1997)
Sorting error (1997)
Where is f2? (1997)
Error -108 (1997)
possible, WebCat2.0 and checkboxes-restated (1997)
how to post without certain data appearing in the html source (2001)