Re: unusual search problem

This WebDNA talk-list message is from

1998


It keeps the original formatting.
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 Software eCommerce / Web Developer Tools http://www.smithmicro.com Associated Messages, from the most recent to the oldest:

    
  1. Re: unusual search problem (John Hill 1998)
  2. Re: unusual search problem (Martin Gertz Bech 1998)
  3. Re: unusual search problem (Kenneth Grome 1998)
  4. Re: unusual search problem (Kenneth Grome 1998)
  5. Re: unusual search problem (John Hill 1998)
  6. Re: unusual search problem (PCS Technical Support 1998)
  7. unusual search problem (Kenneth Grome 1998)
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 Software eCommerce / Web Developer Tools http://www.smithmicro.com John Hill

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:

Showif Context combined with Search (1997) Version 4? (2000) Integration with SQL (1997) Exclamation point (1997) reading a email (2000) Help formatting search results w/ table (1997) Shopping Cart Problem (1998) Setting up shop (1997) Separate SSL Server (1997) WebCat2b13 Mac plugin - [sendmail] and checkboxes (1997) emailer (1997) WC1.6 to WC2 date formatting -FIXED! (1997) problem: type 2 errors (1997) Emailer (WebCat2) (1997) Extended [ConvertChars] (1997) [WebDNA] exclusivelock (2011) Multiple catalog databases and showcart (1997) show all problem (1997) Forcing Search w/ URL (1999) Automatic Forwarding using WebCat (1997)