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:

Site Test Please (2005) SMSI FTP - calander system (2002) Help name our technology! (1997) SEA files (1996) searching illegal HTML (2002) sort problems....bug or brain fart? (1997) Hard Questions ? (1997) More on the email templates (I like it) (1997) Sorting error (1997) Triggers (1999) PCS Emailer's role ? (1997) Text limits in NT version? (1997) WebCommerce: Folder organization ? (1997) WebCatalog for Postcards ? (1997) Hummm .... (2002) Some Questions (1997) A quickie question (1997) Encrypt (1999) Search/sort in URL Was: GuestBook example (1997) Date Range search (1997)