Niclas Hedhman wrote:
>
> "N. Sean Timm" wrote:
>
> > > One might argue that this is necessary or even recommendable (introduction
> > of
> > > more complexity).
> > If you're going to have a <doc-type> node, I think it either needs to reside
> > in some sort of parameter namespace (which seems messy), or you should have
> > to specify it like the following:
> >
> > <map:param name="doc-type" map:value="bac.dtd"/>
> > or
> > <map:param name="doc-type">bac.dtd</map:param>
>
> Do I?? I must admit that I don't comprehend the Namespace idea to its fullest,
> and I often am mistaken between name space, default name space and resulting
> name space (XSLT).
>
> So someone who is a bit more versed in these things, please work out the
> following dilemma.
>
> The Site map needs the flexibility to add components that have their own
> configuration structure.
> For instance;
> <map:chooser type="clientaddress"
> src="class:///org.apache.cocoon.choosers.ClientAddressChooser">
> <param name="order" value="allow,deny" />
> <param name="all" value="false" />
> <allow host="com" />
> <allow host="com.my" />
> <allow host="se" />
> <deny host="controller.asiaconnect.com.my" />
> </map:chooser>
Yuch. There is no need to "clone" http.conf syntax, we have structure
and order, let's use it!
<map:chooser type="clientaddress" src="...">
<allow>
<host>com</host>
<host map:value="com.my"/>
<host>se</host>
</allow>
<deny>
<host>controller.asiaconnect.com.my</host>
</deny>
</map:chooser>
> Would that mean, to avoid all the possible collisions, and use of XSLT and
> other things, I would need to declare a namespace so that the above instead
> look like;
> <map:chooser
> type="clientaddress"
> src="class:///org.apache.cocoon.choosers.ClientAddressChooser"
> xmlns:cac="http://apache.org/cocoon/components/chooser/ClientAddress"
> >
> <cac:param name="order" value="allow,deny" />
> <cac:param name="all" value="false" />
> <cac:allow host="com" />
> <cac:allow host="com.my" />
> <cac:allow host="se" />
> <cac:deny host="controller.asiaconnect.com.my" />
> </map:chooser>
>
> (The attributes would default to the tag name space, no?)
>
> And I could reduce that with a default namespace;
> <map:chooser
> type="clientaddress"
> src="class:///org.apache.cocoon.choosers.ClientAddressChooser"
> xmlns="http://apache.org/cocoon/components/chooser/ClientAddress"
> >
> <param name="order" value="allow,deny" />
> <param name="all" value="false" />
> <allow host="com" />
> <allow host="com.my" />
> <allow host="se" />
> <deny host="controller.asiaconnect.com.my" />
> </map:chooser>
>
> Now, since at least the latter two is equivalent (as I understand NS), how
> would this affect the Configurations in Cocoon.
> I have noticed that I need to do a
> Enumeration list=conf.getConfigurations( "map:choosers" );
> But, what if the map: prefix is changed (not likely for the sitemap in general,
> but for smaller components yes.)
> Enumeration list = conf.getConfigurations("cac:allow");
> Only works if cac, is used. How do I proceed when the declaration is in the
> default NS, and so on...?
> Do I look it up?
Your approach to namespaces is mechanical. A namespace is "not" part of
the name. In a namespace-aware configuration you would ask for
Configuration conf = getConfigurations("choosers",
"http://mynamespace");
Anyway, since having namespace-aware configuration is (for what I can
see now) useless, I'd say we keep the default namespace for anything
that should not be touched by the sitemap.
This is why "value" is in the sitemap namespace: it should be
transparent to the Configuration objects passed to components.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<stefano@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------