Re: SMSI -- a [notfound] context?

This WebDNA talk-list message is from

2002


It keeps the original formatting.
numero = 41118
interpreted = N
texte = >> How difficult would it be to create a [notfound] tag that's used >> inside a search context -- to list all the records in the db that are >> not found by the search? > >This would be fairly easy to implement. But it should probably be qualified >by a new [search] parameter....[Search db=......&Unmatched=T] then instead >of a new [NotFound] context, just use the existing [FoundItems] context to >display the 'UnMatched' records. This way, other search attributes and >aggregates could still be applied. Thanks for the reply Scott,It doesn't really matter how you implement it, as long as it is possible for us to find the non-matching records and to manipulate those records the same way we can manipulate the [founditems] now.The only reason I suggested a [notfound] context is because if this feature were implemented via a [notfound] context, only one search would have to be performed. With only one search, the [founditems] as well as the [notfound] items could be displayed in two groups within a single search context.However ...Maybe your suggestion is better. Your proposal for an optional &Unmatched=T parameter would require that two separate searches be used to display both the founditems and the unmatched items:[Search db=......] [founditems] [!]these items matched the search terms[/!] [/founditems] [/search][Search db=......&Unmatched=T] [founditems] [!]these items DID NOT match the search terms[/!] [/founditems] [/search]... but the benefit of this approach is obvious: Everything that works inside a search context without the optional parameter will continue to work inside a search context *with* the &Unmatched=T parameter -- including [shownext] and [index] and everything else we use inside our search contexts.Until someone points out any flaws in your approach, I now believe that your suggestion for using an optional &Unmatched=T parameter is better than my original [notfound] suggestion. After all, it's not all that difficult to do two virtually identical searches, one with and one without your optional parameter. And if this approach makes it easier for you to code, then maybe we can have it sooner ... :)But like I said, as long as we can have this capability some day, any method of implementation is better than not having it, right?Thanks Scott -- and everyone else -- for recognizing the value of this potential new feature.:) Sincerely, Kenneth Grome------------------------------------------------------------- Kenneth Grome & Associates US-Asian Business Specialists Philippine Business Office +63 (32) 255-6921 Primary Email Address owner@kengrome.com Alternate Email Address kengrome@webdna.net -------------------------------------------------------------------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/ Associated Messages, from the most recent to the oldest:

    
  1. Re: SMSI -- a [notfound] context? (Donovan 2002)
  2. Re: SMSI -- a [notfound] context? (Kenneth Grome 2002)
  3. Re: SMSI -- a [notfound] context? (Aaron Lynch 2002)
  4. Re: SMSI -- a [notfound] context? (Stuart Tremain 2002)
  5. Re: SMSI -- a [notfound] context? (Alex McCombie 2002)
  6. Re: SMSI -- a [notfound] context? (Scott Anderson 2002)
  7. Re: SMSI -- a [notfound] context? (John Peacock 2002)
  8. Re: SMSI -- a [notfound] context? (Gary Krockover 2002)
  9. Re: SMSI -- a [notfound] context? (Clayton Randall 2002)
  10. Re: SMSI -- a [notfound] context? (Larry Goodhew 2002)
  11. Re: SMSI -- a [notfound] context? (Scott Anderson 2002)
  12. Re: SMSI -- a [notfound] context? (Tim Robinson 2002)
  13. SMSI -- a [notfound] context? (Kenneth Grome 2002)
>> How difficult would it be to create a [notfound] tag that's used >> inside a search context -- to list all the records in the db that are >> not found by the search? > >This would be fairly easy to implement. But it should probably be qualified >by a new [search] parameter....[Search db=......&Unmatched=T] then instead >of a new [NotFound] context, just use the existing [founditems] context to >display the 'UnMatched' records. This way, other search attributes and >aggregates could still be applied. Thanks for the reply Scott,It doesn't really matter how you implement it, as long as it is possible for us to find the non-matching records and to manipulate those records the same way we can manipulate the [founditems] now.The only reason I suggested a [notfound] context is because if this feature were implemented via a [notfound] context, only one search would have to be performed. With only one search, the [founditems] as well as the [notfound] items could be displayed in two groups within a single search context.However ...Maybe your suggestion is better. Your proposal for an optional &Unmatched=T parameter would require that two separate searches be used to display both the founditems and the unmatched items:[Search db=......] [founditems] [!]these items matched the search terms[/!] [/founditems] [/search][Search db=......&Unmatched=T] [founditems] [!]these items DID NOT match the search terms[/!] [/founditems] [/search]... but the benefit of this approach is obvious: Everything that works inside a search context without the optional parameter will continue to work inside a search context *with* the &Unmatched=T parameter -- including [shownext] and [index] and everything else we use inside our search contexts.Until someone points out any flaws in your approach, I now believe that your suggestion for using an optional &Unmatched=T parameter is better than my original [notfound] suggestion. After all, it's not all that difficult to do two virtually identical searches, one with and one without your optional parameter. And if this approach makes it easier for you to code, then maybe we can have it sooner ... :)But like I said, as long as we can have this capability some day, any method of implementation is better than not having it, right?Thanks Scott -- and everyone else -- for recognizing the value of this potential new feature.:) Sincerely, Kenneth Grome------------------------------------------------------------- Kenneth Grome & Associates US-Asian Business Specialists Philippine Business Office +63 (32) 255-6921 Primary Email Address owner@kengrome.com Alternate Email Address kengrome@webdna.net -------------------------------------------------------------------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/ Kenneth Grome

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:

setitems, one more thing (1997) ListWords passing multi values in one form field (2000) Sendmail Excel attachment (2003) Re:E-Mailer (WebCatb15acgiMac) (1997) WebCatalog vs WebDNA (2002) Going to OSX 10.4 Tiger - WebDNA 6 (2006) WebCatalog 3 for Macintosh (1998) Document Contains No Data! (1997) Frames and [cart] (1998) Reversed words (1997) Putting & into a database (1999) problems with WebCat-Plugin (1997) [OT] Google Info (2004) & Problem in Textarea (1999) Where's Cart Created ? (1997) Email template names (1997) For you expert WebDNA coders (was Interesting speed (2003) [SearchString] problem with [search] context (1997) remotely add + sign (1997) Formulas.db + Users.db (1997)