avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@dff.st>
Subject Re: [PATCH] Re: Cascading Configuration
Date Wed, 27 Feb 2002 12:41:11 GMT
On Thu, 14 Feb 2002, Peter Donald wrote:
> On Thu, 14 Feb 2002 19:45, Stephen McConnell wrote:
> > Peter Donald wrote:
> > > Sent: Thursday, 14 February, 2002 08:41
> > > To: Avalon Developers List
> > > Subject: Re: [PATCH] Re: Cascading Configuration
> > >
> > >
> > > I agreee that some form of merging of config trees is useful and
> > > whether it is done via some sort of new merging Configuration
> > > implementation or via some more explicit mechaism then it woulld
> > > still be useful. The client still sees a simple configuration tree
> > > so there does not need to be any knowledge of backend representation.
> > >
> > > However you still didn't answer my queries :) Here are some of them again
> >
> > I didn't answer them because I'm not interested in "merging" :-).
>
> Yes you are - you just choose to call it a different name - your explanations
> demonstrate that quite well ;)
>
> However what really concerns me is the non-intuitive nature of the merging
> process you propose. Namely I would not expect the lone <b/> to be present in
> result in the example
>
> Source: <a><b x="1"/></a>
> Default: <a><b/></a>
> Result: <a><b x="1"/><b/></a>
>
> Even worse was this example
>
> Source: <a><b x="1"/></a>
> Default: <a><b x="2" y="2"/></a>
> Result: <a><b x="1" y="2"/><b x="2" y="2"/></a>
>
> There is also no mechanisms in place for element removal. Nor non-cloning of
> default elements or of ...
>
> When you said
>
> > I do think we should consider management!
>
> I agree which is why I dont like the proposal. It is inflexible and
> non-intuitive ;)

...sorry, I was locked in a dark room getting some work done;)

Anyway - back to problem then... or did we come up with flexible and
intuitive sollution yet ;)

ok... let's discuss the desired behaviour on a more concrete example first:

Source:
  <cocoon version="2.0">
   <xml-parser class="my.JaxpParser" logger="core.xml-parser">
    <parameter name="validate" value="true"/>
    <parameter name="namespace-prefixes" value="true"/>
   </xml-parser>
   <mycomponent>
     config
   </mycomponent>
  </cocoon>
Default:
  <cocoon version="2.0">
   <xml-parser class="org.apache.avalon.excalibur.xml.JaxpParser" logger="core.xml-parser">
    <parameter name="validate" value="false"/>
    <parameter name="namespace-prefixes" value="false"/>
    <parameter name="stop-on-warning" value="true"/>
    <parameter name="stop-on-recoverable-error" value="true"/>
   </xml-parser>
  </cocoon>
Result:
  <cocoon version="2.0">
   <xml-parser class="my.JaxpParser" logger="core.xml-parser">
    <parameter name="validate" value="true"/>
    <parameter name="namespace-prefixes" value="true"/>
    <parameter name="stop-on-warning" value="true"/>
    <parameter name="stop-on-recoverable-error" value="true"/>
   </xml-parser>
   <mycomponent>
     config
   </mycomponent>
  </cocoon>

I think this looks pretty straight forward - unfortunately this seems to
be quite tricky... let's look at the parameters

What would happen if we had:

Source:
  <cocoon version="2.0">
   <xml-parser class="my.JaxpParser" logger="core.xml-parser">
    <parameter name="validate" value="true"/>
   </xml-parser>
   <mycomponent>
     config
   </mycomponent>
  </cocoon>
Default:
  <cocoon version="2.0">
   <xml-parser class="org.apache.avalon.excalibur.xml.JaxpParser" logger="core.xml-parser">
    <parameter name="namespace-prefixes" value="true"/>
   </xml-parser>
  </cocoon>

Of course we would expect as result:

  <cocoon version="2.0">
   <xml-parser class="my.JaxpParser" logger="core.xml-parser">
    <parameter name="validate" value="true"/>
    <parameter name="namespace-prefixes" value="true"/>
   </xml-parser>
   <mycomponent>
     config
   </mycomponent>
  </cocoon>

But couldn't it also be:

  <cocoon version="2.0">
   <xml-parser class="my.JaxpParser" logger="core.xml-parser">
    <parameter name="validate" value="true"/>
   </xml-parser>
   <mycomponent>
     config
   </mycomponent>
  </cocoon>


The default value for attribute "name" is "namespace-prefixes" it then
gets overidden and "name" gets value "validate". So only because we know
the context and therefor what there is (let say) the unique path to the
node we can tell if the attribute "name" is to be overidden or a new
"parameter" node needs to be created.

Actually I have no idea yet to solve this... anyone else?
--
Torsten


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message