On Sunday 04 December 2005 22:32, markharw00d wrote: > I think I'm with Erik on this - I generally don't see end users keen to > type anything other than "words with spaces" as queries.
I think/hope that XSL allows a simplified front end that would fit my needs. > I do see them commonly using GUI forms with multiple inputs and behind > the scenes application code assembling the query - the same way just > about every web app in the world has forms that create SQL on the user's > behalf. > Like SQL, I do see this proposed new query syntax as a language for > developers. > > Aside from the debate over choice of query syntax we would also need to > consider the impact such a language has on the query objects it > instantiates. For the surround language I made a layer of classes between the parser and Lucene in the org.apache.lucene.queryParser.surround.query package. This layer exists mainly because not all the operators in the surround language directly match to Lucene classes. Also, term expansion of truncations is refactored more than in Lucene to allow for a maximum on the total number of expanded terms, regardless of the query structure. I don't know whether such a layer would be needed for an xml based parser. > I like the Spring/Ant approach which uses reflection to wire up beans > generically because this allows new objects to be plugged in to the > framework without having to rewrite the parser. > This "generic wirer" approach requires the wirable objects to obey > JavaBean conventions (zero arg constructor and public getters/setters > for properties). Many existing Lucene Query objects have their mandatory > properties passed into their constructors and so would not directly fit > into such a framework. I can see that changing existing query classes to > provide a no-arg constructor would be a contentious move because it > would make it possible for developers using them directly to mistakenly > instantiate Query objects without passing mandatory parameters. Perhaps > in these cases it would be better to preserve the existing class and > provide a "parser wrapper bean" used purely to integrate the existing > Query class with the new parser framework. That sounds like some good reasons for a layer between the parser and Lucene. Regards, Paul Elschot --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
