hi , The changes can be minimal. Everything remains same . Just a small modification for DOMUtil#addToNamedList() method can do the trick. All the current handlers will work as it is.
I shall file a jira issue for the same. Let us see what is the best solution --Noble On Thu, Jul 3, 2008 at 7:02 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote: > I agree and your proposal is reasonable, but I hate to think of us inventing > yet another way to write configuration files and do initialization stuff. I > think we really need to consider Solr 2.0 running on Spring. There is just > no reason why we need to spend so much time and energy on configuration when > it could be done so much cleaner in an IOC container like Spring. > > -Grant > > On Jul 3, 2008, at 3:14 AM, Noble Paul നോബിള് नोब्ळ् wrote: > >> All the components initialized by Solr have an init(NamedList args) >> initializer. This leads us to writing the configuration needed for the >> component in the NamedList format. People familiar with Solr may know >> the format but most of what is wrtten is noise than information. For >> users who are not familiar w/ the format find it too difficult to >> understand why they have to write it this way >> >> For example the spellcheckcoponent have a configuration as follows >> <searchComponent name="spellcheck" class="solr.SpellCheckComponent"> >> <lst name="spellchecker"> >> <str name="name">default</str> >> <str >> name="classname">org.apache.solr.spelling.IndexBasedSpellChecker</str> >> <str name="field">spell</str> >> <str name="spellcheckIndexDir">./spellchecker</str> >> </lst> >> </searchComponent> >> >> The most intuitive format for the above configuration would be >> >> as follows >> <searchComponent name="spellcheck" class="solr.SpellCheckComponent"> >> <spellchecker> >> <name>default</name> >> >> <classname>org.apache.solr.spelling.IndexBasedSpellChecker</classname> >> <field>spell</field> >> <spellcheckIndexDir>./spellchecker</spellcheckIndexDir> >> </spellchecker> >> </searchComponent> >> >> This enhancement can be done automatically by modifying the DOMUtil >> class to read the second format to create the namedlist . The new >> rules for constructing the namedlist can be. >> * if a tag contains subtags it will be treated <lst> >> * The tag name will be considered as the 'name' >> * All the attributes values will be treated as string. >> >> This can be further enhanced w/ the following rule >> * A tag contains attributes will also be a <lst> >> * Each attribute will be a String value >> The following can be made equivalent to >> <searchComponent name="spellcheck" class="solr.SpellCheckComponent"> >> <spellchecker name="default" >> >> classname="org.apache.solr.spelling.IndexBasedSpellChecker" >> field="spell" >> spellcheckIndexDir="./spellchecker"/> >> </searchComponent> >> >> The only problem I see w/ this change is that any plugin that relies >> on the type to be something other than string may fail. But that >> should not be an excuse for all the new components paying the >> "NamedList tax" >> --Noble >> >> >> >> >> >> >> >> -- >> --Noble Paul > > -------------------------- > Grant Ingersoll > http://www.lucidimagination.com > > Lucene Helpful Hints: > http://wiki.apache.org/lucene-java/BasicsOfPerformance > http://wiki.apache.org/lucene-java/LuceneFAQ > > > > > > > > -- --Noble Paul
