Thanks for the tips and comments. 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]
