Sylvain Wallez wrote:

Carsten Ziegeler wrote:

Bertrand Delacretaz wrote:


Le Jeudi, 4 mars 2004, à 14:37 Europe/Zurich, Carsten Ziegeler a écrit :



...I think, we should disable this feature for now and find

a better


and compatible way....

Wouldn't just changing the header name from org.apache.cocoon.sitemap/Location to something like X-Cocoon-debug-sitemap-location fix the problem?



Perhaps in this special case, I don't know, perhaps Lars can answer this.




Using a known prefix like "X-Cocoon-debug-" also makes it easy to filter out these headers when needed.


This information is absolutely not meant to be sent back to the browser!

But then you have to change every component that currently iterates over the parameters and every component has to filter.
We actually really introduced an incompatible feature and to be honest, I don't even know where it is used and if it's useful at all.



I'm the one who introduced this feature: it allows every sitemap component to know the location from where it is invoked, which allows more meaningful messages to be produced by these components. You can find some example usage of this in e.g. AbstractWildcardMatcher and AbstractProcessingPipeline.


The parameters object is the only one that is related to a particular usage of a component in a sitemap statement, and therefore the only place where this information can be stored.

Now I understand the problem Lars encountered, and I'm sorry to have missed that when I implemented that feature (I don't use these parameter-iterating actions).

So how do we solve this? I do want to keep this information which is an important means to provide more help to the developper in case of problem.

So here's a proposal (I should have thought about it way earlier...): let's use a "LocatedParameters", subclass of "Parameters" with an additional "getLocation()" method. It has no impact on components that iterate on parameters, and yet still provide location whenever it's needed.


Does it make sense to narrow the location down even more by passing the parameter name with that method?


location = parameters.getLocation(name);

I am surprised this isn't part of the Parameters interface already.

Unico

Reply via email to