: Something along these lines seems reasonable (that we came up with
: near-identical schema reinforces that). I originally had a list per
: field for multiple fragments as well, though scrapped it for
: simplicity.
:
: Does breaking down the highlit segments give significantly more power
: to the user over simply allowing a custom Formatter?
I'm the wrong guy to ask because i don't use highlighting, and generally
don't care that much about highlighting in my day to day life ... i
suggested that approach initially because:
a) it gave all the power to the remote client
b) doesn't require two pass parsing in the case where the client
wants to use the highlighting information in a way that request
handler isn't aware of (pass one: parse hte Solr response; pass two
parse the highlighting markup)
c) bypasses any issues about highlighting markup escaping (for example, i
think i recall you using "<em>" to denote highlighting correct? what
if the stored field value you are going to highlight is "This is some
<em>stored</em> HTML" ?)
: Not unreasonable. Any objections to augmenting StandardRequestHandler
: with the ability to store config-time param defaults (as DisMax does
: currently)?
I would *love* to see StandardRequestHandler changed in this way ...
there's a lot of refactoring that could be done as well to take advantage
of SolrPluginUtils (it's on the TaskList, it's just that no one has had a
chance to do it yet)
: Should I submit a patch as a starting point?
If you want to tackle adding init params to the StandardRequestHandler as
well as adding highlighting support, I would start with a jira/patch for
the init params -- then open another one that adds highlighting support to
SolrPluginUtils (or wherever) and adds hooks for it into
StandardRequestHandler and/or DisMaxRequestHandler.
Of course: if you've already got some code that's working great and just
has all the options hardcoded (which is what i'm infering you've got
based on what's been discussed so far), then by all means submit it as a
patch as is if you'd like -- best case scenerio we commit it as is and
then refactor some of the stuff into init params later, worst case you can
get more fedback on the code itself early on.
-Hoss
