You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeremy Quinn <je...@media.demon.co.uk> on 2004/06/07 15:14:33 UTC

extending LuceneCocoonSearcher

Hi All

I have developed some CForms that allow you to assemble a set of Beans 
that represent Queries. These are converted directly to Lucene Query 
objects without using the QueryParser.

At the moment, they set up a new Searcher for each hit.

I would prefer to use a cached Component for this like 
LuceneCocoonSearcher.

Would anyone object to my adding the following to the 
LuceneCocoonSearcher Interface and SimpleLuceneCocoonSearcherImpl 
Implementation:

	Hits search(Query query) throws ProcessingException;

and, after we upgrade to Lucene 1.4:

	Hits search(Query query, Sort sort) throws ProcessingException;

where Hits is: org.apache.lucene.search.Hits
where Query is: org.apache.lucene.search.Query
where Sort is  org.apache.lucene.search.Sort



WDYT?

regards Jeremy



--------------------------------------------------------

                   If email from this address is not signed
                                 IT IS NOT FROM ME

                         Always check the label, folks !!!!!
--------------------------------------------------------

Re: extending LuceneCocoonSearcher

Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 7 Jun 2004, at 15:06, Upayavira wrote:

> Jeremy Quinn wrote:
>
>>
>> On 7 Jun 2004, at 14:27, Upayavira wrote:
>>
>>> Jeremy Quinn wrote:
>>>
>>>> Hi All
>>>>
>>>> I have developed some CForms that allow you to assemble a set of 
>>>> Beans that represent Queries. These are converted directly to 
>>>> Lucene Query objects without using the QueryParser.
>>>>
>>>> At the moment, they set up a new Searcher for each hit.
>>>>
>>>> I would prefer to use a cached Component for this like 
>>>> LuceneCocoonSearcher.
>>>>
>>>> Would anyone object to my adding the following to the 
>>>> LuceneCocoonSearcher Interface and SimpleLuceneCocoonSearcherImpl 
>>>> Implementation:
>>>>
>>>>     Hits search(Query query) throws ProcessingException;
>>>>
>>>> and, after we upgrade to Lucene 1.4:
>>>>
>>>>     Hits search(Query query, Sort sort) throws ProcessingException;
>>>>
>>>> where Hits is: org.apache.lucene.search.Hits
>>>> where Query is: org.apache.lucene.search.Query
>>>> where Sort is  org.apache.lucene.search.Sort
>>>>
>>>> WDYT?
>>>
>>>
>>> Looks fine to me.  I'd like to have the beans, too!
>>
>>
>> Thanks Upayavira.
>>
>> The beans are relatively simple.
>> I would be happy to donate them ..... but they deal with our chosen 
>> subset of what a query is to be composed of ...... and that might not 
>> be everybody's cup of tea.
>>
>> I would be happy to send them to you for your evaluation, then see if 
>> you still think they are generally useful ......
>>
>>
>> Incidentally .....
>>
>> The Query Bean has a repeater, to which you add Criterion Beans.
>> At the moment, all Criteria in the form are represented by a 'field', 
>> a 'match' and a 'term', where the 'field' is a popup of Lucene Search 
>> Index fields, match is a popup that can be 'contains', 'like', or 
>> 'phrase' and the term is a textfield.
>>
>> Since some of the fields it is possible to search on are populated 
>> from fixed keyword lists, we would like be able to show a popup of 
>> those keywords instead of the text-field for 'term'. So the display 
>> (what kind of formfield, which selectionlist) of the Criterion would 
>> change depending on the setting of the 'field' property. (A bit like 
>> MacOSX Finder's search window, for those that know it.)
>>
>> How do you do that in CForms?
>>
>> I suspect you need to use those Widgets I never understood like 
>> 'union', 'class', 'struct' etc. Is that the case?
>>
>> Thanks for any suggestions.
>
> Just skimming your mail (got a project to finish by last Friday)...
>
> Have you seen the car selector sample? There's drop downs there that 
> change dependent upon the previous entry. Does that do what you want?

it could be, I will have a look .....
however, sometimes they need to be selectionlists, sometime just a 
simple text field ..... other usecases may require a date field, or 
range etc. etc. so I think it is more complicated than just switching a 
selectionlist on the fly.

regards Jeremy

------------------------------------------------------------------------
"Objective reality is a synthetic construct, dealing with a 
hypothetical universalization of a multitude of subjective realities."
Philip K Dick - "The Electric Ant"

Re: extending LuceneCocoonSearcher

Posted by Upayavira <up...@fwbo.org>.
Jeremy Quinn wrote:

>
> On 7 Jun 2004, at 14:27, Upayavira wrote:
>
>> Jeremy Quinn wrote:
>>
>>> Hi All
>>>
>>> I have developed some CForms that allow you to assemble a set of 
>>> Beans that represent Queries. These are converted directly to Lucene 
>>> Query objects without using the QueryParser.
>>>
>>> At the moment, they set up a new Searcher for each hit.
>>>
>>> I would prefer to use a cached Component for this like 
>>> LuceneCocoonSearcher.
>>>
>>> Would anyone object to my adding the following to the 
>>> LuceneCocoonSearcher Interface and SimpleLuceneCocoonSearcherImpl 
>>> Implementation:
>>>
>>>     Hits search(Query query) throws ProcessingException;
>>>
>>> and, after we upgrade to Lucene 1.4:
>>>
>>>     Hits search(Query query, Sort sort) throws ProcessingException;
>>>
>>> where Hits is: org.apache.lucene.search.Hits
>>> where Query is: org.apache.lucene.search.Query
>>> where Sort is  org.apache.lucene.search.Sort
>>>
>>> WDYT?
>>
>>
>> Looks fine to me.  I'd like to have the beans, too!
>
>
> Thanks Upayavira.
>
> The beans are relatively simple.
> I would be happy to donate them ..... but they deal with our chosen 
> subset of what a query is to be composed of ...... and that might not 
> be everybody's cup of tea.
>
> I would be happy to send them to you for your evaluation, then see if 
> you still think they are generally useful ......
>
>
> Incidentally .....
>
> The Query Bean has a repeater, to which you add Criterion Beans.
> At the moment, all Criteria in the form are represented by a 'field', 
> a 'match' and a 'term', where the 'field' is a popup of Lucene Search 
> Index fields, match is a popup that can be 'contains', 'like', or 
> 'phrase' and the term is a textfield.
>
> Since some of the fields it is possible to search on are populated 
> from fixed keyword lists, we would like be able to show a popup of 
> those keywords instead of the text-field for 'term'. So the display 
> (what kind of formfield, which selectionlist) of the Criterion would 
> change depending on the setting of the 'field' property. (A bit like 
> MacOSX Finder's search window, for those that know it.)
>
> How do you do that in CForms?
>
> I suspect you need to use those Widgets I never understood like 
> 'union', 'class', 'struct' etc. Is that the case?
>
> Thanks for any suggestions.

Just skimming your mail (got a project to finish by last Friday)...

Have you seen the car selector sample? There's drop downs there that 
change dependent upon the previous entry. Does that do what you want?

Regards, Upayavira



Re: extending LuceneCocoonSearcher

Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 7 Jun 2004, at 14:27, Upayavira wrote:

> Jeremy Quinn wrote:
>
>> Hi All
>>
>> I have developed some CForms that allow you to assemble a set of 
>> Beans that represent Queries. These are converted directly to Lucene 
>> Query objects without using the QueryParser.
>>
>> At the moment, they set up a new Searcher for each hit.
>>
>> I would prefer to use a cached Component for this like 
>> LuceneCocoonSearcher.
>>
>> Would anyone object to my adding the following to the 
>> LuceneCocoonSearcher Interface and SimpleLuceneCocoonSearcherImpl 
>> Implementation:
>>
>>     Hits search(Query query) throws ProcessingException;
>>
>> and, after we upgrade to Lucene 1.4:
>>
>>     Hits search(Query query, Sort sort) throws ProcessingException;
>>
>> where Hits is: org.apache.lucene.search.Hits
>> where Query is: org.apache.lucene.search.Query
>> where Sort is  org.apache.lucene.search.Sort
>>
>> WDYT?
>
> Looks fine to me.  I'd like to have the beans, too!

Thanks Upayavira.

The beans are relatively simple.
I would be happy to donate them ..... but they deal with our chosen 
subset of what a query is to be composed of ...... and that might not 
be everybody's cup of tea.

I would be happy to send them to you for your evaluation, then see if 
you still think they are generally useful ......


Incidentally .....

The Query Bean has a repeater, to which you add Criterion Beans.
At the moment, all Criteria in the form are represented by a 'field', a 
'match' and a 'term', where the 'field' is a popup of Lucene Search 
Index fields, match is a popup that can be 'contains', 'like', or 
'phrase' and the term is a textfield.

Since some of the fields it is possible to search on are populated from 
fixed keyword lists, we would like be able to show a popup of those 
keywords instead of the text-field for 'term'. So the display (what 
kind of formfield, which selectionlist) of the Criterion would change 
depending on the setting of the 'field' property. (A bit like MacOSX 
Finder's search window, for those that know it.)

How do you do that in CForms?

I suspect you need to use those Widgets I never understood like 
'union', 'class', 'struct' etc. Is that the case?

Thanks for any suggestions.

regards Jeremy


--------------------------------------------------------

                   If email from this address is not signed
                                 IT IS NOT FROM ME

                         Always check the label, folks !!!!!
--------------------------------------------------------


Re: extending LuceneCocoonSearcher

Posted by Upayavira <uv...@upaya.co.uk>.
Jeremy Quinn wrote:

> Hi All
>
> I have developed some CForms that allow you to assemble a set of Beans 
> that represent Queries. These are converted directly to Lucene Query 
> objects without using the QueryParser.
>
> At the moment, they set up a new Searcher for each hit.
>
> I would prefer to use a cached Component for this like 
> LuceneCocoonSearcher.
>
> Would anyone object to my adding the following to the 
> LuceneCocoonSearcher Interface and SimpleLuceneCocoonSearcherImpl 
> Implementation:
>
>     Hits search(Query query) throws ProcessingException;
>
> and, after we upgrade to Lucene 1.4:
>
>     Hits search(Query query, Sort sort) throws ProcessingException;
>
> where Hits is: org.apache.lucene.search.Hits
> where Query is: org.apache.lucene.search.Query
> where Sort is  org.apache.lucene.search.Sort
>
> WDYT?

Looks fine to me.  I'd like to have the beans, too!

Upayavira