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:

unsubscribe (1997) RE:DatabaseHelper (1997) [REPLACE] inside [FOUNDITEMS] (1998) Where's Cart Created ? (1997) [HIDEIF] inside [FOUNDITEM] (1997) with Link i need to (1997) Date Formats (1997) quit sending me mail!!!!! (1999) Emailer help....! (1997) WebCat .pdf file is still messed up... (2000) [showif] with ! (2000) Blank Orders (2005) Location of Webcat site in folder hierarchy (1997) emailer (1997) Emailer setup (1997) [WriteFile] problems (1997) View a Order file (1999) [WriteFile] problems (1997) quit command on NT (1997) UNSUBSCRIBE (2000)