numero = 20676
interpreted = N
texte = No, converting the plus sign to a space char (%20) isn't a bug. However, it does bugs me. Browsers convert spaces to plus characters as part of the URLizing process (I suppose this saves space since %20 is three characters versus one char and spaces occur so frequently that they need a easy conversion). Thus when we see a plus sign in URLized text we MUST convert it back to a space. Our [url] context doesn't perform this conversion since it creates confusion and isn't necessary since spaces are just as happy when they're %20's. Unfortunately, most browsers don't work this way.The work around is to wrap a [url] context around the plus character (or just specify it as its %xx equivalent) in [search] text. Then WebCat will convert it back to a plus before processing. (you will notice that the [url] context converts + characters, even though they're legal in a URL, for this reason).John.>Here's something that may or may not have a solution:>>1- I'm creating a bunch of these parameters:>>>>by using a search/founditems context on the search page -- to allow tusers to check off as many brandnames as they wish in their searches. In other words, the search must retrieve records having one *OR* more of the brandnames checked -- the *whole* brand name, not just part of it, because some of the brand names have common characters in them.>>2- On the results page, I'm using this search context:>>[search otherparameters&wofieldNamedatarq=[formvariables name=brandname&exact=F][url][value][/url]+[/formvariables]]>>There's only one problem with this technique: The actual search string created by this code makes the plus signs into %20, and that screws up my searches. Here is the parameter created by this code when I check two of the checkboxes:>>&wofieldNamedatarq=US%20West%20GTE%20>>... but what I *wanted* for this parameter is:>>US%20WEST+GTE+>>So why is webcat replacing + with %20? The plus sign is NOT inside the url context, so shouldn't it be passed as is, without being changed into %20?>>Is this a bug?>Is there a work-around available?>>Sincerely,>Ken Grome>808-737-6499>WebDNA Solutions>mailto:ken@webdna.net>http://www.webdna.net John A. Hill, V.P. Marketing Pacific Coast SoftwareeCommerce / Web Developer Tools http://www.smithmicro.com
Associated Messages, from the most recent to the oldest:
No, converting the plus sign to a space char (%20) isn't a bug. However, it does bugs me. Browsers convert spaces to plus characters as part of the URLizing process (I suppose this saves space since %20 is three characters versus one char and spaces occur so frequently that they need a easy conversion). Thus when we see a plus sign in URLized text we MUST convert it back to a space. Our [url] context doesn't perform this conversion since it creates confusion and isn't necessary since spaces are just as happy when they're %20's. Unfortunately, most browsers don't work this way.The work around is to wrap a [url] context around the plus character (or just specify it as its %xx equivalent) in [search] text. Then WebCat will convert it back to a plus before processing. (you will notice that the [url] context converts + characters, even though they're legal in a URL, for this reason).John.>Here's something that may or may not have a solution:>>1- I'm creating a bunch of these parameters:>>>>by using a search/founditems context on the search page -- to allow tusers to check off as many brandnames as they wish in their searches. In other words, the search must retrieve records having one *OR* more of the brandnames checked -- the *whole* brand name, not just part of it, because some of the brand names have common characters in them.>>2- On the results page, I'm using this search context:>>[search otherparameters&wofieldNamedatarq=[formvariables name=brandname&exact=F][url][value][/url]+[/formvariables]]>>There's only one problem with this technique: The actual search string created by this code makes the plus signs into %20, and that screws up my searches. Here is the parameter created by this code when I check two of the checkboxes:>>&wofieldNamedatarq=US%20West%20GTE%20>>... but what I *wanted* for this parameter is:>>US%20WEST+GTE+>>So why is webcat replacing + with %20? The plus sign is NOT inside the url context, so shouldn't it be passed as is, without being changed into %20?>>Is this a bug?>Is there a work-around available?>>Sincerely,>Ken Grome>808-737-6499>WebDNA Solutions>mailto:ken@webdna.net>http://www.webdna.net John A. Hill, V.P. Marketing Pacific Coast SoftwareeCommerce / Web Developer Tools http://www.smithmicro.com
John Hill
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...