cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: DO NOT REPLY [Bug 27432] New: - Malformed HTTP headers (debug information in Parameters object)
Date Thu, 04 Mar 2004 21:56:51 GMT
Unico Hommes wrote:

>
>
> Sylvain Wallez wrote:
>
>> Carsten Ziegeler wrote:
>

<snip/>

>>> 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.


Although individual parameter location may be useful, the location 
parameter I'm talking about is that of the statement. This makes me 
think "SitemapParameters" with a "getStatementLocation()" is better than 
"LocatedParameters" I suggested above.

Let's consider the following snippet:
10 ...
11   <map:generate src="foo.xml">
12     <map:parameter name="bar" value="baz"/>
13   </map:parameter>
14 ...

((SitemapParameters)parameters).getStatementLocation() --> 
"sitemap.xmap:11:2"
parameters.getLocation("bar") --> "sitemap.xmap:12:4"

getLocation(name) can be useful to notify a problem about a particular 
parameter, while getStatementLocation() relates to the whole statement.

getLocation(name) can also be useful for Parameterizable components, as 
it replaces Configuration.getLocation() which is no more available.

WDYT?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message