: <filter factory="solr.ReflectionFilterFactory" class="...CJKTokenFilter" />
:
: I think this way, the config terms are a bit clearer... What do you think?
in general, do i think it would be better if the <filter> and <tokenizer>
declarations used "factory" as the attribute instead of "class"? ...yes.
So i think it makes sense to change this now? ... i don't know.
the backward compatibiily issues are tricky ... not from an implementation
standpoint, but from a clarify standpoint.
we could always make hte schema.xml parsing code say that <filter> and
<tokenizer> declarations will first be checked for a "factory' attribute,
and if it's found use that class, if it's not found then revert to the
"legacy" behavior of looking for a "class" attribute ... but that means
that as people with existing schemas start to take advantage of newer
factories like the ReflectionFactory, and maybe cut/paste examples
from other configs, they'll start to have a hodgepodge of syntax...
<filter class="solr.LowerCaseFilterFactory" />
<filter factory="solr.SomeOtherFilterFactory" blahblah="true"
yadayadaydad="false" numOption="42" />
<filter class="solr.YetAnotherFilterFactory" />
<filter factory="solr.ReflectionFilterFactory
class="org.apache.lucene.contrib.FooFilter" />
<filter class="solr.OneMoreFilterFactory" />
...i don't know that the "clarity" a "factory" attribute would add for new
users would balance out the confusion this might cause to existing users.
-Hoss
