Hi Thomas, On Mon, Nov 24, 2014 at 3:30 PM, Thomas Mueller <[email protected]> wrote: > (With "full-text parsing" I understand parsing a full-text expression, > which consists of one or multiple "contains" conditions, into a > FullTextExpression AST. If you have a different understanding, then please > tell me.)
I want to treat following two differently 1. FulltextExpression created out of simple string term passed to a single jcr:contains in a query 2. FulltextExpression by combining multiple jcr:contains For #1 it would be better to get access to raw string and pass it to Lucene analyzer for tokenization. For #2 it would be preferable to get the FullTextExpression AST such that it can be mapped to required Lucene query On Mon, Nov 24, 2014 at 3:30 PM, Thomas Mueller <[email protected]> wrote: > As for the "mountain is big" example, the problem seems to be the > query-time aggregation, not the parsing of the expression in the query > engine, and not the use of the FullTextExpression. If you want to get the > term "mountain is big" from the FullTextExpression, use > FullTextExpression.toString() ("Get the string representation of the > condition."). That can be done but then how can I distinguish from a FulltextExpression created out of "mountain is big" and _jcr:contains("title","mountain is big")_So if fulltext expression can provide some hint from what it was constructed from that might help Chetan Mehrotra
