On 2/6/2014 12:53 AM, Earl Hood wrote:
On Tue, Feb 4, 2014 at 6:05 PM, Michael Sokolov wrote:
Thanks for the feedback. I think it's difficult to know what to do about
attribute value highlighting in the general case - do you have any
suggestions?
That is a challenging one since one has to know how attribute data will
be transformed for rendering purposes.
I do not know the workings of Lux, so I cannot provide any specific
suggestions on what Lux can do. I would need time to dive into it.
However, one solution is to workaround the limitation by preprocessing
the data in a form that is friendly to Lux (or at least the highligher).
For example, if I have attribute data I know will be transformed into
renderable content, I would transform it into element-style content,
which should be more friendly for indexing and highlighting purposes.
Lux's XmlHighlighter wraps matching text in an XML element tag. The
name of the tag is configurable. But it won't work for attribute values
since XML doesn't allow "<" in an attribute value. I think Olivier's
suggestion of providing a callback is interesting; that way we can
provide the user much greater control, and the "highlighter" can
actually become more of a query-driven document-processing engine: you
could imagine fairly complex document transformations driven by Lucene
query matching.
I created http://issues.luxdb.org/browse/LUX-73 to track that. If
anybody is interested in continuing this discussion, I'd suggest picking
it up over on Lux's mailing list at lu...@luxdb.org since this seems a
little off topic here.
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
