Re: The max=0 issue is a bug ... CALL TO ACTION

This WebDNA talk-list message is from

2000


It keeps the original formatting.
numero = 29275
interpreted = N
texte = on 3/19/2000 6:08 PM, Kenneth Grome at ken@simplewebstores.com wrote:>> It would make sense not to use variables with names such as max, >> append, replace, delete, shownext, startat, AllReqd, group1field, AllHit, >> AllCase, allBLNK etc. > > This has nothing to do with the problem. Every parameter name above -- except > for max -- can be passed into a search tag or context normally, and it will > still have the same value INSIDE the search tag or context that it had OUTSIDE > that tag or context.My point is not whether this is a bug or not, just that there is a mostly undocumented list of variable names and database field names that should be avoided. And my own methodology is to go through the docs and find any and all command, parameter, and context names and simply avoid using them in any other way than what is prescribed. Not that this 'fixes' a bug, but that it just avoids finding out that there is one. Like using an underscore or some other unique and non-conflicting character string as a prefix to all database fields (other than SKU, etc.) is good preventative methodology. I don't mean to sound like I've avoided these problems completely myself, just that every time it has bitten me, I've sworn to be more methodical about how I name my variables and fields in the future. Sure, this is most likely a bug, but a sentence added to the docs would cure that; making it just a reserved word not recommended as a variable name. This is not as mission critical as the [thisURL] bug in the unix version or the listfiles parameters bug in the NT version (is this also a problem on unix?). Those are bugs. Instead of this particular dialogue, I propose that we as a group begin a list of reserved strings that we have become aware of that we should avoid using as variable or field names so that finding them in the archive is made easier. And I start with these:Do not use as variable or field name: 1. max 2. raw 3. section <-- only because of a bug in Explorer 4. url 5. delete, search, append, replace, founditems, etc. 6. ipaddress, referrer, browsername, httpheader, etc.Do not use as variable name: 1. sku, email, price, etc (special strings required in db for ecommerce)Behaves differently when invoked within the context of an orderfile: 1. date I've left many off of these lists in an effort to get some group cooperation. Now, if everyone would just copy and paste this list into a reply with their addition, we might come up with a definitive list faster than SM can, and maybe, come up with strings that (like max as Ken has found, or raw like I identified a couple of weeks ago) may not even be known by SM themselves.Mike ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Associated Messages, from the most recent to the oldest:

    
  1. IE bug... (was: Re: The max=0 issue is a bug ... CALL TO ACTION (Joseph D'Andrea 2000)
  2. Re: The max=0 issue is a bug ... CALL TO ACTION (Mike Davis 2000)
  3. Re: The max=0 issue is a bug ... CALL TO ACTION (Clint Davis 2000)
  4. Re: The max=0 issue is a bug ... CALL TO ACTION (Chuck Rice 2000)
  5. Re: The max=0 issue is a bug ... CALL TO ACTION (Kenneth Grome 2000)
  6. Re: The max=0 issue is a bug ... CALL TO ACTION (Mike Davis 2000)
  7. Re: The max=0 issue is a bug ... CALL TO ACTION (Chuck Rice 2000)
  8. Re: The max=0 issue is a bug ... CALL TO ACTION (Jesse Proudman 2000)
  9. Re: The max=0 issue is a bug ... CALL TO ACTION (Mike Davis 2000)
on 3/19/2000 6:08 PM, Kenneth Grome at ken@simplewebstores.com wrote:>> It would make sense not to use variables with names such as max, >> append, replace, delete, shownext, startat, AllReqd, group1field, AllHit, >> AllCase, allBLNK etc. > > This has nothing to do with the problem. Every parameter name above -- except > for max -- can be passed into a search tag or context normally, and it will > still have the same value INSIDE the search tag or context that it had OUTSIDE > that tag or context.My point is not whether this is a bug or not, just that there is a mostly undocumented list of variable names and database field names that should be avoided. And my own methodology is to go through the docs and find any and all command, parameter, and context names and simply avoid using them in any other way than what is prescribed. Not that this 'fixes' a bug, but that it just avoids finding out that there is one. Like using an underscore or some other unique and non-conflicting character string as a prefix to all database fields (other than SKU, etc.) is good preventative methodology. I don't mean to sound like I've avoided these problems completely myself, just that every time it has bitten me, I've sworn to be more methodical about how I name my variables and fields in the future. Sure, this is most likely a bug, but a sentence added to the docs would cure that; making it just a reserved word not recommended as a variable name. This is not as mission critical as the [thisurl] bug in the unix version or the listfiles parameters bug in the NT version (is this also a problem on unix?). Those are bugs. Instead of this particular dialogue, I propose that we as a group begin a list of reserved strings that we have become aware of that we should avoid using as variable or field names so that finding them in the archive is made easier. And I start with these:Do not use as variable or field name: 1. max 2. raw 3. section <-- only because of a bug in Explorer 4. url 5. delete, search, append, replace, founditems, etc. 6. ipaddress, referrer, browsername, httpheader, etc.Do not use as variable name: 1. sku, email, price, etc (special strings required in db for ecommerce)Behaves differently when invoked within the context of an orderfile: 1. date I've left many off of these lists in an effort to get some group cooperation. Now, if everyone would just copy and paste this list into a reply with their addition, we might come up with a definitive list faster than SM can, and maybe, come up with strings that (like max as Ken has found, or raw like I identified a couple of weeks ago) may not even be known by SM themselves.Mike ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Mike Davis

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:Dumb Question about Docs (1997) Make sure I understand this??? (1997) WC2.0 Memory Requirements (1997) Cancel Subscription (1996) WC 2.0 frames feature (1997) Email Set-Up? (1997) Cobalt RaQ2 and WebCatalog: who uses it? (2000) Stop the madness. (1997) Apache freak-out with webDNA (2008) Converting order file to database (1998) File upload to database ? (2001) different show next (1997) Visitor info (2000) Introduction/Tutorial/QuickStart (1997) sendmail error (1997) WebCat2b13MacPlugIn - [include] (1997) webcat- multiple selection in input field (1997) WebCat2: Items xx to xx shown, etc. (1997) WebCat2 several catalogs? (1997) Img in goodpath (2001)