: that for a newbie, there is a certain confusion when it comes to "one
: thing with comma a separated list, the other can have multiple
: values". This could also be solved perfectly in the wiki (i.e. making
: it very clear multiple GET params with the same name can be used, or
: if a comma-separated list should be used).
We've certainly tried to be consistent about this. Any param that
"parses" the value you give it should say so on the wiki ("sort" goes into
a lot of detail on this, as does "fl" ... things like "qf" forthe
DismaxHandler could probably be more explicit about spliting on whitespace
instead of just giving an example). Any param that can be specified
multiple times should say "This parameter can be specified multiple
times..." and explain how multiple values will be interpreted.
If you notice any inconsistencies or vagueness in the wiki, feel free to
clean it up (if you don't know what the right thing to write is, just ask)
... I've said it many times in the past: "Experts" tend to be the worst
documentation writters for new users, because they are too aware of how
things work to really understand what type of information is most needed
(or already obvious) to new users.
*Hopefully* I'll get some time tomorow to make progress on SOLR-555 and we
won't have ambiguious wiki pages for plugins with inconsistently formated
sections on each param -- we can start having more explict structured info
about all of the concepts that are really "core" to how a param works (ie:
name, datatype, is it multivalued, can it be overridden per field, what
is/are the value(s) used for). Of course: the "structured" documentation
built from the code would still link to (or dare i say: iframe include?)
wiki pages where users can add notes, comments, and additional exampless
of configuration and use. (much like the PHP documentation, which really
setthe bar for integrating "refrence" documentation with user contributed
adendums)
-Hoss
