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 Mon, 08 Mar 2004 11:48:27 GMT
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.


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 

- 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 


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

View raw message