On Sep 8, 2006, at 4:40 PM, Chris Hostetter wrote:
ignoring the issues of URL escaping and what exactly it would look
like,
something that would allways be possible if we add a method to
SolrParams
get all param names (HttpServletRequest already has this) but it
puts the
power in the hands of the client generating the request -- what i'm
suggesting is putting more power in the hands of the people
configuring
the index.
i'm +1 on this idea that the server should be configurable in ways
the client cannot affect, if so desired, or configured such that the
client has control over all the parameters - but let's make the
controllability of parameters configurable itself. surely there are
some projects (spring and/or hivemind perhaps?) that have this
concept? ant has some very nice outside-in configurability with
properties and "overriding" for example, but you can generally always
control ant properties from the command-line as the last say on
things. this provides a very layered mechanism. but not quite the
model we want for solr parameterization.
There's certainly no reason we can't do both -- what you're describing
would just affect the relationship of the request params with the
<lst name="defaults"> when they get bundled into a DefaultSolrParams;
what i'm describing would be the relationsihp between *that* set of
params and a
new "<lst name="appended"> set.
i have to plead that i'm not following all of these parameter issues
closely, other than to adjust my ruby code to match the changes with
the highlighter, and i've just tried the (wonderful!) faceted
feature. i'd like to add a "more like this" facility along these
lines, at least i have that within my custom request handler. this
architecture pleases me!
Erik
