Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
Ben Nadel at BFusion / BFLEX 2009 (Bloomington, Indiana) with: Timothy Farrar
Ben Nadel at BFusion / BFLEX 2009 (Bloomington, Indiana) with: Timothy Farrar

SRCHR - A Client-Only YQL-Powered Search Engine With jQuery

By Ben Nadel on

A couple of weeks ago, YayQuery podcaster, Rebecca Murphey posted a blog entry about a project called SRCHR. This was supposed to be a 100% client-side search engine powered by YQL (Yahoo Query Language) and jQuery. The idea behind this post was to crowd-source the development of such an application such that we could see the various ways in which different people might approach the same thick-client problem. This kind of development is something very new to me, so I thought it would be a very valuable experience to have. The following is a demo of my SRCHR solution (which you can try for yourself):


SRCHR - A Client-Only, YQL-Powered Search Engine With jQuery.  

My solution is not feature-complete. The application is supposed to cache the "recent queries" list across page refreshes; but, local storage is not something that I have worked with before, and honestly, I need to get back to preparing my Scotch On The Rocks presentations. As such, the code allows for a pre-defined list of recent queries, but does not provide any caching mechanism.

The search interface was supposed to be easily scalable, so I tried to build the various components with as little coupling as a I could. Both the search form and the search results are passed a collection of search engine instances that are used to build the UI. In this way, the various interfaces have no preconceived notion of what they are supposed to support and will scale as the collection of search engines changes.

The actual searching is performed by various "Search Engines" that implement a core SearchEngine class and return a unified "search result" data format. Using a unified data format, I figured I could easily add search engines so long as they knew how to normalize their inherent search results to fit into the agreed-upon data format. The actual display of the data is handled by the search results controller. As such, the search engines don't have to know anything display and the search results controller doesn't have to know anything about the search engines.

Like I said, this kind of development is way outside of my comfort zone, so I am sure there is a ton of room for improvement. If you'd like to look at the code, feel free to download it here.

Reader Comments


Thanks my man. As I was building this, I thought it would be an awesome project to see how people accomplish the same thing in FLEX. Maybe I can get someone to review this with me as part of my "FLEX On jQuery" series.

I believe this feature complete:

Thanks for posting about this, it was a lot of fun building the site. I'm with you on the client side stuff, I looked over some of the localStore/sessionStorage implementations, but I was not willing to wrestle with that. Query caches are just stored in an internal structure.


Looks good my man. Don't forget to post a link to it on Rebecca Murphey blog post (linked in my blog post) as she is the one who organized the project.