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:
Re(2): Append command (1999)
[authenticate] (2000)
Problem with [Search] inside of [Loop]? (1997)
WebCat, The Trend, & Consolidating... (1997)
My slower response (1997)
RE: protect tag not working (1998)
View Source from cache (1997)
Using files in an Email broadcast (1999)
WebCatalog NT beta 18 problem (1997)
CountChars (2004)
Appending Record Prob (2001)
Help formatting search results w/ table (1997)
WebCat2 several catalogs? (1997)
searches with dash, period etc. (2000)
WebCat2 - Getting to the browser's username/password data (1997)
Banner DNA (1997)
RE: Automatic Forwarding using WebCat (1997)
Help with Shipping Costs (1997)
SET (1998)
WebCommerce: Folder organization ? (1997)