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" <[EMAIL PROTECTED]> To: "Lucene Users List" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
