On Sep 24, 2011 7:44 AM, "Greg Pendlebury" <email@example.com
> Hey Demian,
> I like the design choice of splitting things up. That class has been calling
> out for a refactor.
> I'm curious if you can see a clean way to store the more complicated objects
> in search history and saved searches, but otherwise your design direction
> seems good.
> "Sent from Ye Olde mobile device. Forgive my fat fingers and their typos."
> p: +61 7 3295 1187, m: 0403 674 810, e: firstname.lastname@example.org
> On Sep 23, 2011 10:42 PM, "Demian Katz" <email@example.com
>> 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
>> If you want to actually look at some of the code I'm talking about, here
> are some places to start:
>> Search Objects:
>> Generic Search Controller:
>> Search Results View:
>> Thanks for bearing with me. I'm happy to answer any questions, and I look
> forward to hearing your thoughts.
>> - Demian
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> Vufind-tech mailing list