[MTOS-dev] Implementing new MT::App::Search

[Timothy Appnel]

Good to see some action in this area. Its long overdue.

I haven't got over every line of code -- I don't think that would be
productive at this point if I had. There are a few high-level points I
wanted to make light of in the interpretation of my work before
comments on a few of Fumiaki's points.

XSearch was intended to provide a pluggable system for more then just
public blog search. This was a design goal from the start. Inside the
CMS application was a consideration as was a CLI script. I never got
around to doing these latter two cases to see if what's there holds
up, but I think I was pretty close. This is partially why XSearch was
a separate module and not an App module that could with presumptions
and baggage that I though limited the frameworks use.

The framework was to do a little as possible to facilitate pluggable
search. Said differently XSearch was to make as few assumptions as
possible. Of course it had to make some, but things like what it would
search, what context is would create, how query strings are
constructed and interpreted where up to the plugin developer and NOT
the framework.

These two points seem to have been lost in translation from what I can
tell in my quick glance.

More below.

On 2/29/08, Fumiaki Yoshimatsu <fyoshimatsu at sixapart.com> wrote:

>  Second of all, the new MT::App::Search should be 100% backwards
>  compatible with the current MT::App::Search.  The implementation I
>  checked in leaves the entire code in MT::App::Search::Legacy class and
>  you can always use it by just changing what application is bootstrapped
>  in mt-search.cgi.  The new one should also leverage as many config
>  directives as possible and should be able to use all of the search
>  related template tegs.

Agreed though there are a few currently in existence that are of
dubious use. (Is generating an edit entry link really necessary for
search?)

>  Last but not the least, the new frameworks must be simple.  Because this
>  is the first iteration, we are not yet 100% sure how search plugins
>  would want to use the framework, I want the framework has as little
>  "required to be implemented" items as possible.  In fact I am to change
>  how search classes should implement search_terms method which returns
>  "terms" and "args" to pass to load_iter method later, because it seems
>  too restrictive.  I also want the framework leverage all the existing
>  infrastructure such as MT::Template::Context class for modeling search
>  results and existing template tags for user interface.

I agreed with simple and encourage you to simplify some more. For
instances, I saw code for parsing the query string -- that should be
up to the search plugin developer to decide. Its one thing if you want
to provide a series of utility methods that said developer can use if
its applicable, but its another to force them.

Personally I'd just assume see Lucene::QueryParser[1] used and not
reinvent the wheel.

I also saw that a search template is presumed. What if I just want to
dump the results into a JSON structure? Using a module and not a
template would be the easier thing to do.

http://search.cpan.org/~simon/Lucene-QueryParser-1.04/QueryParser.pm

>  Speaking of which, I also would like to know if it is OK to leave any of
>  these features currently found in mt-search behind.  Is there that many
>  use of the features?
>  * Regexp search
>  * Case sensitive search
>  * NOT, AND and OR atoms

>  In other words, should whitespace separated search keywords be enough
>  for blog readers?

I guess it depends on what you are talking about. I'm getting confused
as to what is the framework and what is the built-in app. To me these
where two separate things -- one that was built on top of another.

None of these should be in the framework. I'm indifferent to them
being in the base search. I never used them and don't know of anyone
who is.

<tim/>

-- 
Timothy Appnel
Appnel Solutions
http://appnel.com/