lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <e...@ehatchersolutions.com>
Subject Re: Lucene Taglib
Date Tue, 09 Mar 2004 03:51:29 GMT
On Mar 8, 2004, at 10:21 PM, Iskandar Salim wrote:
> Thanks for the tips and comments.

Also, there was a big smiley implicit in my JSP taglib rantings below.  
Certainly no offense intended.  I've paid my Struts/taglib dues and am 
now deep into a completely different web development paradigm that I 
find quite enjoyable and refreshing.

Your taglib is a nicely done.

	Erik



>
> Regards,
> Iskandar
>
> ----- Original Message -----
> From: "Erik Hatcher" <erik@ehatchersolutions.com>
> To: "Lucene Users List" <lucene-user@jakarta.apache.org>
> Sent: Monday, March 08, 2004 7:48 PM
> Subject: Re: Lucene Taglib
>
>
>> On Mar 8, 2004, at 3:46 AM, Iskandar Salim wrote:
>>> I've worked on a bit on the taglib and added an "index" and "field"
>>> tag for
>>> basic indexing capability, though I don't think it's really useful,
>>> apart
>>> from, in my case quick prototyping of web applications. What do you
>>> guys
>>> think? I'm new to Lucene and taglibs so I may have missed out lots of
>>> things.
>>
>> I don't think a taglib is a useful place to put indexing code.  Your
>> mileage may vary, but there are so many flags to control (field type,
>> analyzer, boost, etc) that it is more cleanly done directly with the
>> Lucene API.
>>
>>> For the curious, you see the 'in progress' examples and docs at
>>> http://www.javaxp.net/lucene-examples/ and
>>> http://www.javaxp.net/lucene-doc/
>>>
>>
>> Nice work fleshing out documentation!
>>
>>> Erik, is there any requirements for the java package names? e.g. ...
>>> to be
>>> named as org.apache.lucene.taglib etc.
>>
>> Yes, that package name is the best one probably.
>>
>>> BTW, I've included the ASL 2.0 license in the source files.
>>
>> Thanks!
>>
>> A few comments/suggestions:
>>
>> - What if I wanted an index to live in a RAMDirectory and have it live
>> in application scope?  My suggestion here is instead of using a path
>> for the index, use a Directory.  This allows greater freedom for the
>> developer, and it should be pretty easy to craft a JSTL expression to
>> wrap a string path into an FSDirectory (I don't know JSTL, but if it
>> cannot do this then I'm disappointed - I'm in the Tapestry/OGNL world
>> myself, where it would be trivial).
>>
>> - Or, perhaps you may want a long-lived IndexSearcher so that a
>> Directory is only needed to construct the IndexSearcher?
>>
>> - I haven't looked at your code, but is 'keywords' passed directly to
>> QueryParser?  If so, perhaps that should be renamed 'query' instead
>> since keywords is more domain-specific and has sort of a special
>> meaning in Lucene as a Field.Keyword
>>
>> - What about allowing specification of an Analyzer?  Look at how this
>> is done in the sandbox contributions/ant area in IndexTask.  I allowed
>> the user to specify high level strings like 'whitespace', 'stop',
>> 'standard', etc. as well as a fully-qualified classname.  I can only
>> assume you have it hardcoded to use a particular analyzer, which is 
>> not
>> going to be generally useful.
>>
>> - It would also be nice if you allowed for an optional filter to be
>> specified - in this case I think it would probably suffice to just
>> allow a Filter instance to be passed in rather than the taglib itself
>> constructing one.  This allows capabilities like search-within-search
>> and more.
>>
>> - What is the 'content' attribute for the search tag?  Is that the
>> default field?  If so, again, I think it would be best to named the
>> similarly to the Lucene terminology - just call it 'field', or
>> 'defaultField'.
>>
>> - SortedMap?  What are you sorting on?  Is count necessary since you
>> can just ask the map what its size is?
>>
>> In general it looks fine though, although I cringe seeing the amount 
>> of
>> "code" your examples have in it with all the scriptlet junk.  It seems
>> quite yucky to me given that I'm now in the elegant Tapestry world
>> where I could hide the *entire* tag in an HTML template with something
>> like this:
>>
>>     <table jwcid="results"/>
>>
>> and no, I'm not kidding, and yes, there would be more behind the 
>> scenes
>> but separate from the "view".  And the example includes all the paging
>> controls.
>>
>> Erik
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: lucene-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org


Mime
View raw message