Dan Shirah schreef:
Hello,
I'm hoping to get a few good ideas on the best way to perform a search of
PHP results.
Currently I have a page that returns a list of collapsed customer data:
Example
+ John Smith
+ Jane Doe
+ Robert Jones
+ Dale Bennett
If the user clicks on a customer name it will expand the selection:
Example
- John Smith
- 123 Anywhere Street
- myCity
- myState
- myZipcode
- myWebsite
+ Jane Doe
+ Robert Jones
+ Dale Bennett
Now, what my client wants is a Search functionality that will allow him to
type in myState and have the application automatically expand and focus on
the first match. Then, be able to click "Next" and have it collapse the
first result and expand the next result that contains the same state.
Any ideas?
I was thinking that maybe I would have to create a temp table so it could be
searched against, but I'm not sure if that is the best idea. Also, in order
to save processing time, the way I made the above expanding/collapsing list
is I don't not pull in the customer details intially but instead run a query
and get the details when the name is clicked for expansion. This is because
there could be potentially 1,000's of result and getting all of the names
and all of the details at page load would 1) take longer than a user is
willing to wait 2) exceed the timeout 3) exceed the memory allocation
I would think about caching data to streamline searching ... it would
be very helpful if your address data was normalized when possible (e.g.
states are related to users based on a database id rather than being
loose bits of text) .. so that you can precalculate (e.g. via a cronjob) user
ids
that 'match' against certain strings) ... where you stick your cache is upto
you.
I would also cache the structured data for each user so that you can
very quickly output (e.g. via JSON) the data for a given user/users
to the browser.
And then the fun part: build an ajaxy wotsit that paginates, sorts, searches
and highlights the data ... and then couple it to server scripts that
use the precalculated data to cough up matching users id (for searches) and
userdata (for display).
most of the hardwork will be in building the client side magic, the
scripts that act as an interface on the precalculated data will be simple,
and the precalculation routines shouldn't be to hairy (although you'll have
to think careful about how to cover all your angles when it comes to the
kind of data that can be search through)
Thanks for any help/ideas.
I'm interested to know if my brainfart made any sense to you :-)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
