PARAMETER vs. OPERATOR (was The BUG is BACK ...)

This WebDNA talk-list message is from

1998

It keeps the original formatting. numero = 18635
interpreted = N
texte = >>[showif [url][itemName][/url]^[url]<[/url]]>>The simplest thing is to look at what [url][itemName][/url]^[url]<[/url]>looks like in a web page. If you see that < displays as plaintext, then>you would need to create a ConvertChars database that changes those special>characters to something that will compare correctly.It displays as %3C ...But I still have a problem with the fact that the [url] wrapping suggestion failed to work properly. In fact it *SHOULD HAVE* worked properly, right? After all, it was suggested because it was expected to work but did not, so to me that suggests a bug in the software itself ... and I have other evidence to indicate that there is very likely a bug in the software ...Apparently a typical CONTAINS comparison cannot be done when there's the slightest chance of a math operator character such as <>!~+=^&*- appearing on the left side of the comparison operator ... right?Just for a review to make sure we all understand what's going on here:All I want is to prevent users from entering < and > into some of my form fields ... because disallowing those characters will effectively prevent them from creating hyperlinks in those fields.So I tried to use this comparison [showif [itemName]^<] to see if the < character was one of the characters entered into the itemName field, but it didn't work, the comparison failed to detect the existence of the < character in that field even though it was clearly there. In fact the < character was the FIRST character in that field, and it also showed up in my [formvariables] tag, thus confirming that it had actually been passed from the form page to the next page.So a suggestion was made for me to wrap both parameters of the [showif] comparison in [url] contexts, as shown in the first line of this email message. Apparently this is supposed to make WebCat understand that the < character which appears in the [itemName] parameter is not the OPERATOR in the showif tag, it is actually a PARAMETER instead. So I tried this suggestion but it still didn't work ...What presumeably happened is that the < characters on both sides of the comparison were changed from < to %3C ... because that's what the [url] context changes them to ... and then they were compared to each other using the CONTAINS operator. But even that comparison failed ... :(Now the *new* suggestion is to forget about that [url] wrapping idea, and try using [convertchars] instead -- with a special database, of course. But before I spend any more time on this, I feel as if there are some critical questions that need to be answered first, because these questions get to the source of the problem that still seems to be recurring:1- Why doesn't the character string %3C compare properly? It really *SHOULD* compare properly, after all that's why the [url] wrapping suggestedwas made in the first place ...2- Is there something special about %3C that breaks WebCatalog's showif and hideif comparison capabilities? We already know there's something about using < that breaks it, because that's the character that fails in every one of my tests when it's the first character in the parameter -- but oddly enough it seems to be okay when it's NOT the first character in the parameter (so what's that all about?).3- Does this problem have something to do *SPECIFICALLY* with the CONTAINS operator (^)? That's the comparison operator I'm using ... so that's one place to look for a potential bug in the software. Maybe that's the source of all these problems, who knows?4- If that's not the problem, then we really need to know and understand which keyboard characters or strings of characters will *ALWAYS* work properly inside our showif and hideif comparisons? And which characters or strings of characters will *FAIL* to work properly, either some of the time or all the time?If these problems are possibly being caused by a bug, then until it gets fixed, it becomes an exercise in futility to try yet another new *work-around* technique to resolve a problem that may actually be impossibe to resolve because it's internal to the software code itself.All I really know is that from a WebCat user's standpoint, I feel I should be able to rely on WebCat to do the *right thing* in my showif and hideif comparisons -- all the time! Now that I've discovered this unusual new problem, it no longer seems I can do that ...CONCLUSION:It *appears* that the primary reason for WebCat's failure here is because it cannot tell the difference between a PARAMETER and an OPERATOR in a showif or hideif comparison ... at least when using the CONTAINS (^) operator ... in certain situations ... :(Sincerely,Ken Grome808-737-6499WebDNA Solutionsmailto:ken@webdna.nethttp://www.webdna.net Associated Messages, from the most recent to the oldest:

Re: PARAMETER vs. OPERATOR (was The BUG is BACK ...) (Kenneth Grome 1998)
Re: PARAMETER vs. OPERATOR (was The BUG is BACK ...) (PCS Technical Support 1998)
PARAMETER vs. OPERATOR (was The BUG is BACK ...) (Kenneth Grome 1998)

>>[showif [url][itemName][/url]^[url]<[/url]]>>The simplest thing is to look at what [url][itemName][/url]^[url]<[/url]>looks like in a web page. If you see that < displays as plaintext, then>you would need to create a ConvertChars database that changes those special>characters to something that will compare correctly.It displays as %3C ...But I still have a problem with the fact that the [url] wrapping suggestion failed to work properly. In fact it *SHOULD HAVE* worked properly, right? After all, it was suggested because it was expected to work but did not, so to me that suggests a bug in the software itself ... and I have other evidence to indicate that there is very likely a bug in the software ...Apparently a typical CONTAINS comparison cannot be done when there's the slightest chance of a math operator character such as <>!~+=^&*- appearing on the left side of the comparison operator ... right?Just for a review to make sure we all understand what's going on here:All I want is to prevent users from entering < and > into some of my form fields ... because disallowing those characters will effectively prevent them from creating hyperlinks in those fields.So I tried to use this comparison [showif [itemName]^<] to see if the < character was one of the characters entered into the itemName field, but it didn't work, the comparison failed to detect the existence of the < character in that field even though it was clearly there. In fact the < character was the FIRST character in that field, and it also showed up in my [formvariables] tag, thus confirming that it had actually been passed from the form page to the next page.So a suggestion was made for me to wrap both parameters of the [showif] comparison in [url] contexts, as shown in the first line of this email message. Apparently this is supposed to make WebCat understand that the < character which appears in the [itemName] parameter is not the OPERATOR in the showif tag, it is actually a PARAMETER instead. So I tried this suggestion but it still didn't work ...What presumeably happened is that the < characters on both sides of the comparison were changed from < to %3C ... because that's what the [url] context changes them to ... and then they were compared to each other using the CONTAINS operator. But even that comparison failed ... :(Now the *new* suggestion is to forget about that [url] wrapping idea, and try using [convertchars] instead -- with a special database, of course. But before I spend any more time on this, I feel as if there are some critical questions that need to be answered first, because these questions get to the source of the problem that still seems to be recurring:1- Why doesn't the character string %3C compare properly? It really *SHOULD* compare properly, after all that's why the [url] wrapping suggestedwas made in the first place ...2- Is there something special about %3C that breaks WebCatalog's showif and hideif comparison capabilities? We already know there's something about using < that breaks it, because that's the character that fails in every one of my tests when it's the first character in the parameter -- but oddly enough it seems to be okay when it's NOT the first character in the parameter (so what's that all about?).3- Does this problem have something to do *SPECIFICALLY* with the CONTAINS operator (^)? That's the comparison operator I'm using ... so that's one place to look for a potential bug in the software. Maybe that's the source of all these problems, who knows?4- If that's not the problem, then we really need to know and understand which keyboard characters or strings of characters will *ALWAYS* work properly inside our showif and hideif comparisons? And which characters or strings of characters will *FAIL* to work properly, either some of the time or all the time?If these problems are possibly being caused by a bug, then until it gets fixed, it becomes an exercise in futility to try yet another new *work-around* technique to resolve a problem that may actually be impossibe to resolve because it's internal to the software code itself.All I really know is that from a WebCat user's standpoint, I feel I should be able to rely on WebCat to do the *right thing* in my showif and hideif comparisons -- all the time! Now that I've discovered this unusual new problem, it no longer seems I can do that ...CONCLUSION:It *appears* that the primary reason for WebCat's failure here is because it cannot tell the difference between a PARAMETER and an OPERATOR in a showif or hideif comparison ... at least when using the CONTAINS (^) operator ... in certain situations ... :(Sincerely,Ken Grome808-737-6499WebDNA Solutionsmailto:ken@webdna.nethttp://www.webdna.net Kenneth Grome

DOWNLOAD WEBDNA NOW!

PARAMETER vs. OPERATOR (was The BUG is BACK ...)

1998

Top Articles:

Related Readings: