Can someone please explain the principle behind how you store search results return to allow people to return to a page of search results and don't have to search again.
So if my page shows the results of a query and when a users clicks on a link in one the rows to go to a detail page, when they click a link saying "back to search results" it would take them back to the master page with the previous search results already showing.
Sure I can create it myself, I could just do with knowing the concept behind it.
You can do it a few ways, depending in the criteria used and how "expensive" the query is.
More often than not, you can save the search params and just build a URL from them.
I prefer this as it's simple and it's obvious, it also means the user can bookmark this search, send it onto friends easily etc etc.
I'm not sure if you can store the query's result set in a session variable. If not, you could transfer the data in the result set to a session variable and then loop through the session variable (result set or array) to redisplay the query results on subsequent calls to the page.
store the query's result set in a session variable seems a good option.
Do I do that on the master page before the user leaves or on the detail page?
I would create the session variable on the master page, which is where I assume the query is run initially.
At the top of the page, first check if the session variable isset(). If it is, then loop through the session variable to display the query results. If the session variable does not exist, then run the query and then store the query results in a session variable for subsequent calls to the master page.
In my previous post
If not, you could transfer the data in the result set to a session variable and then loop through the session variable
should have been
If not, you could transfer the data in the result set to an array session variable and then loop through the session variable........
By the by really, but if you were to log the search query terms and find that there are recurring terms that are used frequently enough -- and you feel the search is "expensive", you can then in the future arrange to cache the html segment for page 1 of those results.
Its only worth doing this if you can prove both cases because you have search-term logging enabled.
After weeks, or even months you learn all kinds of other stuff about your users if you log search terms too, it may also lead you to change how your site works -- plus you have the absolute proof to show your client why the UX should be altered and in a way you will provide valuable insight about user behaviour.
I'm confused now.
With the above I assume you are talking about storing results for a single user session and not for when a user returns in another session, say the next day.
The other suggestions in this thread are referring to users returning in another browser session as far as I can see.
IMO, storing the result-set in the session is unnecessary here; and cumbersome.
But if the op doesn't want to run the query again, what are other options? If i understand your suggestion correctly, the query would have to be run again which is not what the op wants afaik when he/she said
and don't have to search again.
Also, if the number of returned rows is not relatively large, then I don't have any issues with storing them in a session variable. It's a trivial amount of extra code to store in a session variable.
If you want to store the results, put them in the database as Cups suggested along with the params and a hash of the params. This way, if someone else lands on the search page with the exact same parameters you can leverage your cached results too. If not, the query is ran and cached again reducing the load even further.
Just hash the params and find any records with that hash and return the serialised result set.
Let the database do the storage, thats what it's there for.
My interpretation of "not search again" is allowing the user to see their previous results with re-entering the search params.
But even Cups and you put conditions on your suggestions. So we are all making assumptions here on what we think is best for the op's particular situation.
The op has a few options now and they can go with whichever they are most comfortable with
I'm not wanting push this, but the only assumption I'm making is that the query maybe expensive and my proposed solution addresses this should this be an issue. Storing the result-set in the users session directly, doesn't address any issues does it?
I guess they're different solutions, to the same problem...
The OP was looking for the concept behind re-showing result sets as far as I understood. I was just suggesting another way to skin this particular cat as the correct solution is dependent on the perennial "it depends..." question.
But, yes, the OPs original question leaves much open to assumption. Site search strategies are highly linked to usability -- and IMO discovering the correct one for each case tends to be rather more than a mere efficiency question -- is the point I was trying to make.
Big thanks guys. I got stuck in and had it sorted in about ten minutes.
Nice to have varied opinions and approaches.
Works perfectly now and I will know how to do it every time from now on.
This topic is now closed. New replies are no longer allowed.