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 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.
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.
Cheers,
Mark
___________________________________________________________
Yahoo! Model Search 2005 - Find the next catwalk superstars - http://uk.news.yahoo.com/hot/model-search/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
