Sounds like a win-win then :)

On 26 September 2011 22:46, Demian Katz <demian.katz@villanova.edu> wrote:

Regarding storing the more complicated objects in search history, that actually didn’t prove to be a problem – for backward-compatibility, I’m continuing to use the minified search objects you created – I just wrote a new “deminify” routine which translates the stored data into the new data structure.  In fact, the storage actually works a little bit better now – VuFind 1.x has some rather ugly hacks using search type to figure out which type of object to build (i.e. Summon vs. WorldCat vs. Solr).  I’ve retained that logic for backwards compatibility, but new objects minified by VuFind 2 will simply store their class as part of the data structure so they can deminify to the right type of object.  And, of course, if we ever want to eliminate the need for backward compatibility, we can write a routine to deminify and then reminify all of the objects in the database as part of an upgrade script.

 

- Demian

 

On Sep 24, 2011 7:44 AM, "Greg Pendlebury" <greg.pendlebury@gmail.com> wrote:
> 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.
>
> Ta,
> Greg
>
> ==========
> "Sent from Ye Olde mobile device. Forgive my fat fingers and their typos."
>
> p: +61 7 3295 1187, m: 0403 674 810, e: greg.pendlebury@gmail.com
> On Sep 23, 2011 10:42 PM, "Demian Katz" <demian.katz@villanova.edu> wrote:
>> 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
>>
>>
> ------------------------------------------------------------------------------
>> 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.
>> http://p.sf.net/sfu/splunk-d2dcopy2
>> _______________________________________________
>> Vufind-tech mailing list
>> Vufind-tech@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/vufind-tech