Bulk close for Solr 1.4

Maybe there should be two 'Full Interface' pages?

The current Full Interface page has the "handing a bomb to a baby" problem for very large indexes. For example, some things like sorting or faceting can kill a large index. Maybe the super-full page would include a default of 5 seconds for the solr timeout?

Anything that's commonly used should be in Solr's equivalent of advanced search

Agreed ... but there is a risk that some "common" options aren't ubiqutious, so if we add them to the form people could get confused if a param doesn't work because the request handler they are using doesn't support it

in the case of fq, i think the pros outway the cons ... that's why i committed your patch.

I'm curious why we're not interested in making a more advanced UI?

i don't remember anyone saying that ... i just don't think hardcoding a bunch of params into form.jsp is the way to go. i'd love to see a good UI that could inspect the solr conifuration and display the appropriate options in a GUI – ala the wiki page i mentioned (but aparently didn't link to) ...

http://wiki.apache.org/solr/MakeSolrMoreSelfService

Anything that's commonly used should be in Solr's equivalent of
advanced search. Users ask me what is a filter query, they don't
know exists, and end up writing clauses that should be filters
in the query section. Putting fq in the form.jsp will hopefully
help.

I'm curious why we're not interested in making a more advanced
UI?

Yeah, I kinda cringed with this one myself, but it's a basic one that seems reasonable to add... but then so could a defType selector, etc. Now we're talking Solr Explorer and the realm of front-end frameworks like Flare, Solritas, and others popping up.

I'm generally opposed to a proliferation of params on the admin search form (unless we add a way for them to be configured ala MakeSolrMoreSelfService) but fq is at least as ubiquitous as highlighting at this point.

Committed revision 806303.

Patch