lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Iskandar Salim" <iskan...@fused.com.sg>
Subject Re: Lucene Taglib
Date Tue, 09 Mar 2004 03:21:22 GMT
Thanks for the tips and comments.

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


Mime
View raw message