Re[2]: The max=0 issue is a bug ...
This WebDNA talk-list message is from 2000
It keeps the original formatting.
numero = 29310
interpreted = N
texte = This is justifiably a bug if it only occurs in the Mac version; I just tested the Linux Version and it also works fine. I always use [ShowNext max=1], so that I only have one link, since I find it looks amaturish to have a long list of next groupings. I think most people will page through a select set, rather than jumping around.As for variable naming, most languages take the easy english language variable names for themselves and require the _user_ to stay out of _their_ way. This is hardly unique to WebCat; can you imagine how many web sites would have broken if 3.07-f1 changed all of the variables from PCSDate to SMSDate? What you are asking is unreasonable, pure and simple. You should be the one using prefixes, like myDate, etc. Do a search on the web for Hungarian Notation (or its inventor Charles Simonyi) which is a specific way to create variable names that everyone (who knows the code) can immediately recognize.Surely, you must remember that all WebCat field names used to be hard-coded, not to mention the single database...John Peacock____________________Reply Separator____________________ Subject: Re: The max=0 issue is a bug ... Author:
(WebCatalog Talk) Date: 3/20/00 10:17 AM>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:
| |
- Re[2]: The max=0 issue is a bug ... (jpeacock@univpress.com 2000)
|
This is justifiably a bug if it only occurs in the Mac version; I just tested the Linux Version and it also works fine. I always use [ShowNext max=1], so that I only have one link, since I find it looks amaturish to have a long list of next groupings. I think most people will page through a select set, rather than jumping around.As for variable naming, most languages take the easy english language variable names for themselves and require the _user_ to stay out of _their_ way. This is hardly unique to WebCat; can you imagine how many web sites would have broken if 3.07-f1 changed all of the variables from PCSDate to SMSDate? What you are asking is unreasonable, pure and simple. You should be the one using prefixes, like myDate, etc. Do a search on the web for Hungarian Notation (or its inventor Charles Simonyi) which is a specific way to create variable names that everyone (who knows the code) can immediately recognize.Surely, you must remember that all WebCat field names used to be hard-coded, not to mention the single database...John Peacock____________________Reply Separator____________________ Subject: Re: The max=0 issue is a bug ... Author: (WebCatalog Talk) Date: 3/20/00 10:17 AM>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
jpeacock@univpress.com
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:
Windows 2.1b2 Append Bug? (1997)
Post size Limit? (1998)
Separate SSL Server (1997)
[browsername] (2001)
Re:Dumb Question about Docs (1997)
[WebDNA] Secure Cookies (2009)
Can WC remember people? (1998)
Requiring that certain fields be completed (1997)
Help with Repost Data msg from form (1997)
lineitems not showing when moving to a different OS (2006)
too many nested ... problem (1997)
WebDNA 6 (2004)
Group search doesn't work. (1997)
[WebDNA] BBEdit WebDNA Configuration.plist (Language Module) (2013)
Re:Emailer setup (1997)
catagories (1997)
[searchString] (1997)
Webcatalog 4.0 on Mac OS & WebStar (2000)
WebCat b13 CGI -shownext- (1997)
2.0Beta Command Ref (can't find this instruction) (1997)