[VuFind-Tech] VuFind 2 SearchObject Design

[Demian K. <dem...@vi...>]

I'm hoping to get some feedback on my redesign of the SearchObject in VuFind 2.  I've tried to get away from some flaws in the design of the 1.x SearchObject, but I recognize that my new design may have a different set of problems, so I'm interested to hear what others have to say.  This is going to be a long email, but hopefully an informative one.

VUFIND 1.x SEARCHOBJECT DESIGN

The VuFind 1.x SearchObject is a somewhat monolithic beast.  It's a huge class with many methods, and its role bleeds between the model and the controller.  I don't mean to unduly criticize the work that Greg Pendlebury did to build this thing -- it's a huge improvement over the scattered, redundant code that preceded it, and at least some of the problems are the result of my subsequent hacking.  In any case, now that we've been living with it for a while, there is room for further improvement.

Main problems:

- Too much code in one class -- it's hard to follow the logic because so many semi-related functions coexist together.
- Violation of MVC design pattern -- the SearchObject class knows too much about the context in which it is called, reducing its usefulness as a stand-alone object.  It pulls lots of data out of superglobals like $_GET, and I particularly dislike the code that says "if I'm running inside the Author module, do this... otherwise, do that".
- Inconsistent return values; different child classes of the base SearchObject class return entirely different data structures from methods with the same names (most significantly the search result format varies significantly).  This makes it harder to mix and match search objects and reuse controller code.

VUFIND 2 SEARCHOBJECT DESIGN

In VuFind 2, the monolithic search object is gone, replaced by three different classes that nest inside each other like Russian dolls.

- The Search Options class loads fixed search parameters that cannot change -- i.e. settings found in .ini files; things like the list of legal sort options.
- The Search Parameters class loads user-initiated search parameters and validates them against a Search Options object where appropriate.
- The Search Results class takes a Search Parameters object as input, performs a search, and then provides a public interface to obtain information about the results.

Additionally, further specific functionality can be deferred to helper classes (currently there is just one, which encapsulates all the logic related to building URLs from options found in a Search Parameters object).

How this addresses the problems noted above:

- Some of the classes are still quite large, but distributing code among four classes splits it up better than having it in just one place.  However, the fact that each individual class is now simpler has to be weighed against the fact that the overall structure now requires more explanation, and sometimes it's hard to remember which class contains which method.  It's possible that I have taken the factoring too far and should move back a little closer to the original monolithic design -- I'm particularly interested in feedback on this point.
- The Parameters class extracts all of its values from a Zend request object, which means that you can easily load it with values taken from the HTTP context, but you can also construct a dummy object and pass in your own set of parameters if you want to control it in some other way -- more flexible than the hard-coded $_GET references of the old SearchObject.  All of the classes can be more easily controlled from the outside, either by setting parameters or by extending classes, meaning that controller-specific code inside the search objects can now be moved outside to the actual controller where it belongs or at least into a separate subclass with an obvious purpose.
- I'm making an effort to make return values more consistent -- for example, when possible, search results are represented as arrays of record drivers rather than as arbitrary engine-specific formats.

One other general note about the VuFind 2 design: the view templates are doing a bit more work than they used to.  Rather than having the controller assign countless variables for the view, I've instead opted to send the results object to the view and let it call methods.  This gives more flexibility for offering different behavior in different themes, it makes the controllers much more lightweight, and it makes some code easier to reuse.

If you want to actually look at some of the code I'm talking about, here are some places to start:

Search Objects: https://vufind.svn.sourceforge.net/svnroot/vufind/branches/vufind2/library/VF/Search/
Generic Search Controller: https://vufind.svn.sourceforge.net/svnroot/vufind/branches/vufind2/library/VF/Controller/Search.php
Search Results View: https://vufind.svn.sourceforge.net/svnroot/vufind/branches/vufind2/application/themes/blueprint/templates/search/results.phtml

Thanks for bearing with me.  I'm happy to answer any questions, and I look forward to hearing your thoughts.

- Demian