lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
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.


> Regards,
> Iskandar
> ----- Original Message -----
> From: "Erik Hatcher" <>
> To: "Lucene Users List" <>
> 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
>>> and
>> 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message