Just another Perl shrine | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Something like this has been on my to-do list for a long time. One of the big problems was interface design. But that is firming up in my head. FYI, there would be little impact on server load. The list of matching node IDs would go into a hidden field in the form. There would be a limit on how many matching nodes you could collect. You'd still have to hit "Next" to search the next chunk of the DB. Note that I don't find much need for this when using Super Search. I'm almost always searching within a specific section, for a specific author, or within a fairly small date range, etc. So most of my uses of Super Search have searched as far as I want them to after the first 'submit'. On the occasions when I have to hit 'Next', I've usually reviewed the nodes found (if any) and perhaps popped the most promising of them into separate windows/tabs. But being able to carry the list of selected nodes around would be handy and reasonable to implement. I like having a check box for each match and having a radio button for "keep only" vs. "keep all but" with the default being to "keep all but" (when you hit "Next"). And, when hitting "New Search", the option to "discard previous matches" (default), "add to previous matches ('or')", or "refine only previous matches ('and')" (if MySQL can do this efficiently enough that I don't need to worry about doing it in batches). Each time you hit "Next", I would only show the new finds and a count of previous finds and have a button to bring up the entire list. - tye In reply to Re: Getting Complete Listing Of [Super Search] Results (to-do)
by tye
|
|