Re: [WebDNA] passing a variable in an include - precedence
This WebDNA talk-list message is from 2015
It keeps the original formatting.
numero = 112525
interpreted = N
texte = 93 Well, I=92m not overly passionate about this one=85 don=92t get me wrong = ;-).. just trying to explain what it was that I posted. Also, I see this =93issue=94 as perhaps more than one issue.. a simple = issue of the inlculde tag vars not being able to be overwritten or = treated like other vars in regards to scope, etc.., and perhaps touching on the bigger issue which is programming clarity in regards to = namespace and other OOP-style programming techniques.=20 This =93issue=94 of the include vars not being able to be overwritten = has only come up for me a small handful of times in my real-life = projects.=20 So, could this be ignored? probably.=20 However, I=92m a fan of code-reuse and scoping (efficiency / security).. = so I=92d like to see WebDNA improve in this area. I=92m also not a fan = of things half-working.. but that may be more due to some mental quirk that I posses, and it may not be = important to this language.=20 Again, I think programming clarity would be helpful in regards to this = subject=85 perhaps driven by the community=85or perhaps driven by the = WSC C++ developer/s.=20 =46rom there (once changes have been made to the engine), concise = documentation could/should be made about it.=20 I do know that quite a few developers use the scoping tools, and use the = &var=3D parameter for include.. so if changes are made to the engine, it = would be good to remain backwards compatible as best as possible.=20 Or, this whole issue could be ignored. ;-)=20 Donovan On Nov 22, 2015, at 6:04 PM, Matthew A Perosi, Psi Prime =
wrote: > All I have to say is... wow. >=20 > So I learned how to use the [include] way back in 1997 with WebCatalog = 3. I also realized a long time ago that the include variables didn't = seem to work as expected. >=20 > Donovan, your rather passionate POV on this is obviously because you = are far more aware of the internal working of what was supposed to be = accomplished than all the rest of us. Now that you have pointed it out, = I see an _extreme_ value in this. >=20 > Clearly what we need here is better documentation. >=20 > -Matthew >=20 > On 11/22/2015 3:02 PM, Donovan Brooke wrote: >> Okay, one email on this.... have to hit a new website deadline today. >>=20 >> In my opinion there *is* something wrong with the way it works now. >>=20 >> 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. >>=20 >> 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] >>=20 >> Over a more standardized solution: >> [include somefile.inc&var=3Dsomevalue] >>=20 >> 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) >>=20 >> 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] >>=20 >> 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] >>=20 >> some.inc: >> [text scope=3Dsecure]var=3D2[/text] [!] ** tried many scope names ** >>=20 >> [include file=3Dsome2.inc] >> =97=97 >>=20 >> I also tried implicitly setting the scope: >> =97=97 >> main page: >> [scope name=3Dsomescope] >> [include file=3Dsome.inc&var=3D1] >> [/scope] >>=20 >> some.inc >> [text scope=3Dsomescope]var=3D2[/text] >>=20 >> [include file=3Dsome2.inc] >> =97=97 >>=20 >> 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. >>=20 >>=20 >> I then decided to try the PHP way by making use of function: >> PHP: >> function includeF($someVar) { >> include ("inc/header.php"); >> } >>=20 >> WebDNA: >> =97=97 >> main page: >> [function name=3Dstartinclude] >> [include file=3Dsome.inc] >> [/function] >>=20 >> [startinclude var=3D1] >>=20 >> some.inc: >> [text scope=3Dstartinclude]var=3D2[/text] >>=20 >> [include file=3Dsome2.inc] >> =97=97 >>=20 >>=20 >> 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 >>=20 >> This *DID* work as a workaround: >> =97=97 >> main page: >> [function name=3Dstartinclude] >> [include file=3Dsome.inc] >> [/function] >>=20 >> [startinclude var=3D1] >>=20 >> some.inc: >> [text scope=3Dglobal]var=3D2[/text] >>=20 >> [include file=3Dsome2.inc] >> =97=97 >>=20 >> See it here: >> http://www.euca.us/admin/tests/include-bug2/test.html >> (note the use '[:named-global:var]=92 in that link) >>=20 >>=20 >> I also tried setting the scope explicitly with my own naming, in the = [function] solution=85 but that did NOT work. >>=20 >>=20 >> Anyway, here is my thoughts on the subject. >>=20 >> 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 >> 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. >>=20 >> 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. >>=20 >> 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. :-) >>=20 >>=20 >> 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 ;-) ) >>=20 >> 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] >>=20 >> That might further the efforts to address the dissimilarities of = setting vars in that tag, vs.. our other methods. >> >=46rom there, you should be able to tie into that space with the = regular scoping features of WebDNA, for example = [:named-thescopename:var] >>=20 >> 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. >>=20 >> Here is a page on this: >> http://www.euca.us/admin/tests/scope.html >>=20 >>=20 >> 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, >>=20 >> Donovan >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> Here is my 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: >> [include file=3Dsomefile.inc&var=3Dsomevalue] >>=20 >> You can=92t overwrite the var value with a text context within = somefile.inc. >> (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.) >>=20 >> 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. >>=20 >> 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). >>=20 >> 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? >>=20 >> 2.) What about the idea of encapsulation for the passed variables? >> ------ >>=20 >>=20 >> On Nov 21, 2015, at 7:59 AM, Kenneth Grome = wrote: >>=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=92t overwrite the var value with a text context >>>>> [text]=85[/text] within somefile.inc. >>>=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 >>=20 >>=20 >>=20 >> --=20 >> Matthew A Perosi >> Corporate Consultant >> Mobile Marketing Expert >> Senior Web Developer >> SEO Analyst & Educator >> matt@psiprime.com >>=20 >> Psi Prime >> 323 Union Blvd. >> Totowa, NJ 07512 >>=20 >> Direct: 888.872.0274 >> Fax: 888.488.5924 >>=20 >> http://www.perosi.com > --------------------------------------------------------- > 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:
93 Well, I=92m not overly passionate about this one=85 don=92t get me wrong = ;-).. just trying to explain what it was that I posted. Also, I see this =93issue=94 as perhaps more than one issue.. a simple = issue of the inlculde tag vars not being able to be overwritten or = treated like other vars in regards to scope, etc.., and perhaps touching on the bigger issue which is programming clarity in regards to = namespace and other OOP-style programming techniques.=20 This =93issue=94 of the include vars not being able to be overwritten = has only come up for me a small handful of times in my real-life = projects.=20 So, could this be ignored? probably.=20 However, I=92m a fan of code-reuse and scoping (efficiency / security).. = so I=92d like to see WebDNA improve in this area. I=92m also not a fan = of things half-working.. but that may be more due to some mental quirk that I posses, and it may not be = important to this language.=20 Again, I think programming clarity would be helpful in regards to this = subject=85 perhaps driven by the community=85or perhaps driven by the = WSC C++ developer/s.=20 =46rom there (once changes have been made to the engine), concise = documentation could/should be made about it.=20 I do know that quite a few developers use the scoping tools, and use the = &var=3D parameter for include.. so if changes are made to the engine, it = would be good to remain backwards compatible as best as possible.=20 Or, this whole issue could be ignored. ;-)=20 Donovan On Nov 22, 2015, at 6:04 PM, Matthew A Perosi, Psi Prime = wrote: > All I have to say is... wow. >=20 > So I learned how to use the [include] way back in 1997 with WebCatalog = 3. I also realized a long time ago that the include variables didn't = seem to work as expected. >=20 > Donovan, your rather passionate POV on this is obviously because you = are far more aware of the internal working of what was supposed to be = accomplished than all the rest of us. Now that you have pointed it out, = I see an _extreme_ value in this. >=20 > Clearly what we need here is better documentation. >=20 > -Matthew >=20 > On 11/22/2015 3:02 PM, Donovan Brooke wrote: >> Okay, one email on this.... have to hit a new website deadline today. >>=20 >> In my opinion there *is* something wrong with the way it works now. >>=20 >> 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. >>=20 >> 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] >>=20 >> Over a more standardized solution: >> [include somefile.inc&var=3Dsomevalue] >>=20 >> 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) >>=20 >> 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] >>=20 >> 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] >>=20 >> some.inc: >> [text scope=3Dsecure]var=3D2[/text] [!] ** tried many scope names ** >>=20 >> [include file=3Dsome2.inc] >> =97=97 >>=20 >> I also tried implicitly setting the scope: >> =97=97 >> main page: >> [scope name=3Dsomescope] >> [include file=3Dsome.inc&var=3D1] >> [/scope] >>=20 >> some.inc >> [text scope=3Dsomescope]var=3D2[/text] >>=20 >> [include file=3Dsome2.inc] >> =97=97 >>=20 >> 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. >>=20 >>=20 >> I then decided to try the PHP way by making use of function: >> PHP: >> function includeF($someVar) { >> include ("inc/header.php"); >> } >>=20 >> WebDNA: >> =97=97 >> main page: >> [function name=3Dstartinclude] >> [include file=3Dsome.inc] >> [/function] >>=20 >> [startinclude var=3D1] >>=20 >> some.inc: >> [text scope=3Dstartinclude]var=3D2[/text] >>=20 >> [include file=3Dsome2.inc] >> =97=97 >>=20 >>=20 >> 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 >>=20 >> This *DID* work as a workaround: >> =97=97 >> main page: >> [function name=3Dstartinclude] >> [include file=3Dsome.inc] >> [/function] >>=20 >> [startinclude var=3D1] >>=20 >> some.inc: >> [text scope=3Dglobal]var=3D2[/text] >>=20 >> [include file=3Dsome2.inc] >> =97=97 >>=20 >> See it here: >> http://www.euca.us/admin/tests/include-bug2/test.html >> (note the use '[:named-global:var]=92 in that link) >>=20 >>=20 >> I also tried setting the scope explicitly with my own naming, in the = [function] solution=85 but that did NOT work. >>=20 >>=20 >> Anyway, here is my thoughts on the subject. >>=20 >> 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 >> 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. >>=20 >> 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. >>=20 >> 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. :-) >>=20 >>=20 >> 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 ;-) ) >>=20 >> 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] >>=20 >> That might further the efforts to address the dissimilarities of = setting vars in that tag, vs.. our other methods. >> >=46rom there, you should be able to tie into that space with the = regular scoping features of WebDNA, for example = [:named-thescopename:var] >>=20 >> 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. >>=20 >> Here is a page on this: >> http://www.euca.us/admin/tests/scope.html >>=20 >>=20 >> 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, >>=20 >> Donovan >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> Here is my 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: >> [include file=3Dsomefile.inc&var=3Dsomevalue] >>=20 >> You can=92t overwrite the var value with a text context within = somefile.inc. >> (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.) >>=20 >> 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. >>=20 >> 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). >>=20 >> 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? >>=20 >> 2.) What about the idea of encapsulation for the passed variables? >> ------ >>=20 >>=20 >> On Nov 21, 2015, at 7:59 AM, Kenneth Grome = wrote: >>=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=92t overwrite the var value with a text context >>>>> [text]=85[/text] within somefile.inc. >>>=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 >>=20 >>=20 >>=20 >> --=20 >> Matthew A Perosi >> Corporate Consultant >> Mobile Marketing Expert >> Senior Web Developer >> SEO Analyst & Educator >> matt@psiprime.com >>=20 >> Psi Prime >> 323 Union Blvd. >> Totowa, NJ 07512 >>=20 >> Direct: 888.872.0274 >> Fax: 888.488.5924 >>=20 >> http://www.perosi.com > --------------------------------------------------------- > 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:
[WebDNA] WebDNA on W2k3 (2009)
[WebDNA] POST method using TCPSend (2013)
Rename folder under WC3 (2000)
emailer (1997)
Emailer not working (1998)
Ads.db (1997)
Cookie Problems (2000)
Web*SSL and WebCatalog (1997)
Header info in content (1998)
Separate SSL Server (1997)
Running 2 two WebCatalog.acgi's (1996)
possible, WebCat2.0 and checkboxes-restated (1997)
Suffix Slowdown? (2004)
[SearchString] usage (1997)
mod_webcatalog2.so.2-40 is garbled (2008)
RAM issue (2006)
Searching for foreign chars (2004)
Emailer (WebCat2) (1997)
Copyright that puppy (1998)
WebDNA dying or ... ? (2005)