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:

WebDNA problem (2006) How true is this? (1999) Problem (1997) Tags in the header (2000) Virtual hosting and webcatNT (1997) sort problems....bug or brain fart? (1997) Order not created error (never mind) (1997) Notepad problems (1998) can webcat create directories on NT? (1997) Append probs, please help (2001) Headers displaying (2000) Separate SSL Server (1997) Secure Web Server (1999) WebCatalog can't find database (1997) [include ...] behavior (1997) build a select list from a db search (2004) How to stop WebCat services on NT? (2000) Color (2000) Firewalls - What's Good? (1999) Linux ODBC and the ODBC Bridge (2000)