If I want to control how Wildcard clauses are handled, I can do it w/ today's QP as well, just extend it and override the appropriate getter method.
The SyntaxParser can produce WildcardQueryNode object which can further be processed on the processing phase. Is there any example when you cannot use the processing phase for that? In conclusion, I think that if we want to have a truly extensible QP, we should start w/ the query syntax first, and my proposal are those opaque terms. Agree, I also think we need to improve a lot the syntax parsing phase. It's really simple and not extensible yet. Opaque terms are interesting, I just don't think users will like to type '@' before the field names, actually the user has no idea why he's typing that @, so there is no need for that. I think we could do a mapping from field name to parser directly. Anyway, this approach would only work for field:term syntaxes, any other different syntax, like xml syntax, will need a different approach. I cannot think about a generic API yet for this approach, any suggestions? On Wed, Aug 12, 2009 at 12:54 AM, Shai Erera <ser...@gmail.com> wrote: > If I want to control how Wildcard clauses are handled, I can do it w/ > today's QP as well, just extend it and override the appropriate getter > method. >
