: I did a small hack and it works like a charm without the above mentioned
: handler. I only activated variable substitution for the FQ for testing
: if you think that is a nice feature I can activate it for the rest.
As i said in my other reply ... i think you should reconsider the approach
you are taking towards your end goal -- but in general, this of allowing
variable substitution in the lucene query params seems pretty slick to me
... a more general solution might be to modify the SolrQueryParser
directly to have a new "void setParamVariables(SolrParams p)" method. if
it's called (with non null input), then any string that SolrQueryParser
instance is asked to parse would first be preprocessed looking for the ${}
pattern and pulling the values out of the SOlrParams instance.
request handlers could then either pass their main params (if they wanted
to allow kitchen sink param substitution) or if they want to be more
robust (ie: Standard and DisMax), they could do what you describe: have a
configured list of param
names that would be used to construct a new instance of SOlrParams
explicitly for the SolrQueryParser -- but i would think that would be be a
good use for a new seperate init param in the solrconfig, it's not hte
kind of thing you'd ever want to let the client specify.
The reason this really seems cool to me is because it the format/params
passing could work in either order: the format could be specificed in the
config with params coming from the client, or the config could list a big
long list of "constant" params that the client could then use however they
want by specifying a format that used them.
-Hoss
