Doktor Search Results Problem

[Robert Graham <in...@gmail.com>]

Hello all,

I've solved several problems lately in the vein of making RefDoc a
success and I think that we are pretty close to having the system in a
form that is ready to publish documentation as it is intended. On the
road to this destination there are many bumps. One that has come up
recently I thought was worth getting some other opinions on.

Currently we have a pipeline that searches the index created from the
selected root folder. The searching and index are done with Lucene, in
Cocoon block form. The Lucene search returns only the top ten results.
Attributes of elements that point to how many others there are as well
as where and how to get at them are also included. The problem is
getting at the other results programatically. I'm not very familiar
with XSP, but I don't think it is the best solution. An aggregator was
my first thought, but you can't be guaranteed of a bounds for the
result set's size.

So the question is just an inquiry about the best way to grab each
page of results in turn and aggregate them into a single file for
processing with XSLT? I'm not sure if there is a simple solution to
this I don't see or if the best one is XSP or a Java class that grabs
the necessary URLs and puts them together.

Any ideas are appreciated.

Robert Graham

Re: Doktor Search Results Problem

[Bertrand Delacretaz <bd...@apache.org>]

Le 8 août 05, à 14:40, Robert Graham a écrit :

> ...Okay. I wasn't sure if a solution like this would be acceptable. It
> accepts HTTP GET variables including pageLength (# of hits displayed
> per page). I'll go with that for now...

It is certainly good enough in view of getting a minimal version of the 
complete chain working. You can always mark such workarounds with FIXME 
for now.

-Bertrand

Re: Doktor Search Results Problem

[Robert Graham <in...@gmail.com>]

Bertrand,

Okay. I wasn't sure if a solution like this would be acceptable. It
accepts HTTP GET variables including pageLength (# of hits displayed
per page). I'll go with that for now.

Robert

On 8/8/05, Bertrand Delacretaz <bd...@apache.org> wrote:
> Hi Robert,
> Le 7 août 05, à 23:30, Robert Graham a écrit :
> 
> > ...The Lucene search returns only the top ten results...
> 
> This number cannot be magical, it must come from the Lucene block code.
> 
> Can you have a look in there? If you look at the use of the "Hits" data
> type you should be able to find the location where it happens (unless
> someone who knows the Lucene block better than I do can tell where to
> change this).
> 
> Or better, run Cocoon under debugger control: start cocoon.sh with
> "servlet-debug" and connect to port 8000 for remote debugging, from any
> IDE that supports remote JVM debugging. This will allow you to step
> through the Lucene block code and find out exactly what's going on.
> 
> I don't think any refdoc document will have more than 100 snippets, so
> you could probably configure the limit to be 100 instead of 10 and be
> done with it, at least for a first prototype.
> 
> -Bertrand
> 
> 
>

Re: Doktor Search Results Problem

[Bertrand Delacretaz <bd...@apache.org>]

Hi Robert,
Le 7 août 05, à 23:30, Robert Graham a écrit :

> ...The Lucene search returns only the top ten results...

This number cannot be magical, it must come from the Lucene block code.

Can you have a look in there? If you look at the use of the "Hits" data 
type you should be able to find the location where it happens (unless 
someone who knows the Lucene block better than I do can tell where to 
change this).

Or better, run Cocoon under debugger control: start cocoon.sh with 
"servlet-debug" and connect to port 8000 for remote debugging, from any 
IDE that supports remote JVM debugging. This will allow you to step 
through the Lucene block code and find out exactly what's going on.

I don't think any refdoc document will have more than 100 snippets, so 
you could probably configure the limit to be 100 instead of 10 and be 
done with it, at least for a first prototype.

-Bertrand