Okay. Here's what I've done so far, and what I believe I have left to do.
Comments, Loic and Geoff?:
1. I've worked out how to move the search code out of the CGI and into a
"Searcher" class. This actually involved renaming the Parser class to
"Searcher" and moving the code in there. A few public methods get renamed
for clarity, several get added, and voila. Because I was working on code
several versions older than what's in CVS, I'll have to perform the whole
modification again, although my analysis documentation should make that
pretty easy. I want to make sure my changes are desired by everyone else
however, since they are pretty radical in my view. See what follows for
even more radical proposals.
2. The Display class currently accesses the database directly to get the doc
info based on the doc IDs in the ResultList returned by the Searcher. I
believe that the ResultList needs to be smartened up to the point where it
can retrieve the info itself and even perform the "match confidence"
computations that Display currently performs to display its stars. I also
believe that Display needs to concentrate on displaying the data returned by
the ResultList and nothing else. Am I going to far here? If I'm correct, I
think I should place higher priority on this higher than on item #3.
3. Moving the Parser code out of the Searcher should be my third task, I
believe, if we reach an agreement on the above items.
I want to show somebody my code, but the OO design is still in quite a mess.
I think Loic's request for a CVS branch is a good idea and would like to
share that branch if I may. I'm really nervous about making such heavy
changes to this working code, although I feel confident I can pull it off.
On Loic's comments earlier:
> When a
> re-implementation becomes
> available at the C/C++ level, I'd be happy to re-write the
> Text::Query module
> to take advantage of it. This will trigger discussions
> because some people
> love to have Perl only programs.
True. I'm one of those people!
> > CGI. But at some point, I want the perl user to be able
> to "prepare" his
> > statement prior to executing it, which means providing a
> parser interface as
> > well as a searcher.
>
> When you say at some point, you mean not for your first
> release, right ?
Yes, definitely. That's much further down the road.
> I agree that a prepare would be nice, with a syntax tree,
> possibly optimized
> as a result. Resolving the query would then only require
> using an already
> parsed query instead of re-parsing it every time. Let me know
> when you want
> to start a discussion on that.
With your dual experience in syntax trees and htdig, I'm sure you'll be the
first one I turn to.
> Had any success in geting a login on CPAN ?
Yep. I'm now a legitimate CPAN contributor!
Thanks all,
Jamie
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED] containing the single word "unsubscribe" in
the SUBJECT of the message.
