Re: The max=0 issue is a bug ...
This WebDNA talk-list message is from 2000
It keeps the original formatting.
numero = 29306
interpreted = N
texte = >Ken - > >I am having a real hard time replicating any of your results. I tried taking a >page with a simple search context and adding [text]max=9[/text] before the >search and Max = [max] inside the context and I always get what I expected Max = >9.I always used to get the same results you are getting, but it looks like SM broke something in a recent version, at least in the Mac CGI. You're using a unix or NT version, aren't you? It seems there are bugs in some platforms that simply do not exist in other platforms. This is probably one of those situations ... >I even tried adding a &Max to the [search] context itself, and it altered >how many records were retrieved by the search, but the displayed text variable >still came out Max = 9.That's exactly what I was doing, but the displayed text variable inside the search context came our max=0, not max=9. >Please include complete code rather than snippets.Okay here it is, but I'm sure it's the same thing you did when you tested this yourself:[text]startat=1[/text] [text]max=9[/text][search db=catalog.db&neskudatarq=[blank]&max=[max]&startat=[startat]][founditems] [index]-[sku]
[/founditems][showif [numfound]>[max]] Show more items: [shownext]
[start]-[end] [/shownext] [/showif][/search]
I cannot even find max listed as a variable inside the search context, just as a >parameter.It's not a parameter inside the search context, it's just a variable, that's why it should have the same value inside the context as outside. Nothing in my code changes the [max] value inside the search context, webcatalog is just changing it on its own -- this means it's a bug. >You may note that the shownext context will not even print anything >at all unless numfound > max, thus removing any need for your showif at all, if >you put all of your text inside the showif.Yes I know this, I've been using this software for years, and from the very beginning I never put all my text inside the shownext context -- because I like to prefix the shownext links with text such as Show more matching items:.Of course I do NOT want this text repeated in every shownext loop, so I have always used a comparison such as [showif [numfound]>[max]] to determine whether or not to show or hide this text.And yes, I know I can do a showif *inside* the shownext loop instead of doing it outside, and I can make it display the text only in the first loop of the shownext. But that's not how I have been doing it all these years, and it wouldn't fix this bug even if I changed my technique now.And I'm not recommending upgrades to my clients if it means my having to fix my their sites because of a bug like this when Sm knows about it now, and they said they would be fixing outstanding bugs in version 3.0.7 this week anyways, so I imagine that they will just fix it along with the other 3.0.7 bugs. >There is no question that anyone using any WebCatalog context name or parameter >name as a variable name should be rapped hard on the knuckles with a metal >ruler. This is a basic, beginner programming mistake.I agree that in a perfect world, none of us should ever use any term in the webdna language as a variable, instead we should always use variables with different names ...... but I have about 8000 hours of experience programming this software, and I know how to avoid things like this -- provided new versions do not introduce bugs that destroy my correctly-written code. If anything, SM should begin by not distributing templates with examples that use tag names as variables ...And all the tags in the webdna language should begin with sms so they will *never* match common words such as date and text and other common words. After all, how many people would think of naming a field in their database [smsDate] or [smsText]?And the field names in the order files should begin with something other than sms but should still begin with an unusual character string -- such as ofh (for 'order file header') or ofl (for 'order file lineitem') -- to insure that they never conflict with common english-language names *OR* with any sms tags in the webdna language ...Unfortunately it didn't occur to the engineers from the beginning that these would be important coding issues, so they went ahead and used all kinds of common english-language names for the webdna language tags and order file field names. Of course this decision has resulted in adding countless hours of debugging and unintuitive work-arounds requirements to our work within the webdna language ... :(Can you imagine how *FEW* problems we would have had if we never needed to worry about creating any work-arounds -- because all the tags and contexts begin with sms? Just think of the webdna language with:[smsDate] instead of [date] [smsText] instead of [text] [ofhCity] instead of [city] for an orderfile header tag [oflPrice] instead of [price] for an orderfile lineitem tag... and all the rest of the webdna language to match these conventions. This would be just TOO CLEAR and TOO SIMPLE, wouldn't it? No more conflicting tag names, no more getting an orderfile date when you really want today's date, etc., etc ...Ah well, I guess we can all dream ... :)================================ Kenneth Grome, WebDNA Consultant 808-737-6499 http://webdna.net ================================------------------------------------------------------------- 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:
>Ken - > >I am having a real hard time replicating any of your results. I tried taking a >page with a simple search context and adding [text]max=9[/text] before the >search and Max = [max] inside the context and I always get what I expected Max = >9.I always used to get the same results you are getting, but it looks like SM broke something in a recent version, at least in the Mac CGI. You're using a unix or NT version, aren't you? It seems there are bugs in some platforms that simply do not exist in other platforms. This is probably one of those situations ... >I even tried adding a &Max to the [search] context itself, and it altered >how many records were retrieved by the search, but the displayed text variable >still came out Max = 9.That's exactly what I was doing, but the displayed text variable inside the search context came our max=0, not max=9. >Please include complete code rather than snippets.Okay here it is, but I'm sure it's the same thing you did when you tested this yourself:[text]startat=1[/text] [text]max=9[/text][search db=catalog.db&neskudatarq=[blank]&max=[max]&startat=[startat]][founditems] [index]-[sku]
[/founditems][showif [numfound]>[max]] Show more items: [shownext] [thisurl]?startat=[start]>[start]-[end] [/shownext] [/showif][/search] I cannot even find max listed as a variable inside the search context, just as a >parameter.It's not a parameter inside the search context, it's just a variable, that's why it should have the same value inside the context as outside. Nothing in my code changes the [max] value inside the search context, webcatalog is just changing it on its own -- this means it's a bug. >You may note that the shownext context will not even print anything >at all unless numfound > max, thus removing any need for your showif at all, if >you put all of your text inside the showif.Yes I know this, I've been using this software for years, and from the very beginning I never put all my text inside the shownext context -- because I like to prefix the shownext links with text such as Show more matching items:.Of course I do NOT want this text repeated in every shownext loop, so I have always used a comparison such as [showif [numfound]>[max]] to determine whether or not to show or hide this text.And yes, I know I can do a showif *inside* the shownext loop instead of doing it outside, and I can make it display the text only in the first loop of the shownext. But that's not how I have been doing it all these years, and it wouldn't fix this bug even if I changed my technique now.And I'm not recommending upgrades to my clients if it means my having to fix my their sites because of a bug like this when Sm knows about it now, and they said they would be fixing outstanding bugs in version 3.0.7 this week anyways, so I imagine that they will just fix it along with the other 3.0.7 bugs. >There is no question that anyone using any WebCatalog context name or parameter >name as a variable name should be rapped hard on the knuckles with a metal >ruler. This is a basic, beginner programming mistake.I agree that in a perfect world, none of us should ever use any term in the webdna language as a variable, instead we should always use variables with different names ...... but I have about 8000 hours of experience programming this software, and I know how to avoid things like this -- provided new versions do not introduce bugs that destroy my correctly-written code. If anything, SM should begin by not distributing templates with examples that use tag names as variables ...And all the tags in the webdna language should begin with sms so they will *never* match common words such as date and text and other common words. After all, how many people would think of naming a field in their database [smsDate] or [smsText]?And the field names in the order files should begin with something other than sms but should still begin with an unusual character string -- such as ofh (for 'order file header') or ofl (for 'order file lineitem') -- to insure that they never conflict with common english-language names *OR* with any sms tags in the webdna language ...Unfortunately it didn't occur to the engineers from the beginning that these would be important coding issues, so they went ahead and used all kinds of common english-language names for the webdna language tags and order file field names. Of course this decision has resulted in adding countless hours of debugging and unintuitive work-arounds requirements to our work within the webdna language ... :(Can you imagine how *FEW* problems we would have had if we never needed to worry about creating any work-arounds -- because all the tags and contexts begin with sms? Just think of the webdna language with:[smsDate] instead of [date] [smsText] instead of [text] [ofhCity] instead of [city] for an orderfile header tag [oflPrice] instead of [price] for an orderfile lineitem tag... and all the rest of the webdna language to match these conventions. This would be just TOO CLEAR and TOO SIMPLE, wouldn't it? No more conflicting tag names, no more getting an orderfile date when you really want today's date, etc., etc ...Ah well, I guess we can all dream ... :)================================ Kenneth Grome, WebDNA Consultant 808-737-6499 http://webdna.net ================================------------------------------------------------------------- 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
Kenneth Grome
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:
Hidden or Forbidden? (1998)
WC2b12: Yes, Formulas.db is for real (1997)
Can this be done? (2003)
Searching the same field with 2 form variables. (2000)
Multi shift click (1999)
success - serial numbers and webmerch (1997)
practicing safe queries.. (2000)
Appendfile memory usage (redux) (2003)
using showpage and showcart commands (1996)
Location of Browser Info.txt file (1997)
WebCat2b15MacPlugin - [protect] (1997)
Parsing args without ? (2003)
[WebDNA] Record click-thrus (2008)
Protect usage (1999)
WebCat2 several catalogs? (1997)
back button loses cart (2000)
PCS Frames (1997)
RE: Credit card processing - UK (1997)
user submitted data REPOST (2000)
[isfile] ? (1997)