Wow, that's a nice one :)
Now, I think passing this debug information into the Parameters is not
the correct way to go. It can cause - as we see - problems and in
addition this is an incompatible change! So all sitemap components
that are iterating over the parameters object are affected by this
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
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
Bertrand Delacretaz wrote:
Le Jeudi, 4 mars 2004, à 15:01 Europe/Zurich, Carsten
Ziegeler a écrit :
Bertrand Delacretaz wrote:
...Using a known prefix like X-Cocoon-debug- also makes
it easy to
filter out these headers when needed.
But then you have to change every component
Le Jeudi, 4 mars 2004, à 15:07 Europe/Zurich, Carsten Ziegeler a écrit :
...Yes, so if someone knows where this is used/useful we can perhaps
think about an alternative.
It is used to add location info to Exceptions, for example in
o.a.c.matching.AbstractRegexpMatcher.preparedMatch()
(search for
Bertrand Delacretaz wrote:
Le Jeudi, 4 mars 2004, à 15:07 Europe/Zurich, Carsten Ziegeler a écrit :
...Yes, so if someone knows where this is used/useful we can perhaps
think about an alternative.
It is used to add location info to Exceptions, for example in
agreed, 'nice one' was my reaction also :-)
I ran into this already some weeks ago, probably should have reported it
on the mailling list. It is in my upgrade 'report' however :-), but I
didn't consider it a bug or so. We're using a pagination component that
started behaving really weird
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
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
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
Le Jeudi, 4 mars 2004, à 22:56 Europe/Zurich, Sylvain Wallez a écrit :
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
Sylvain Wallez wrote:
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
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
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
13 matches
Mail list logo
