cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Alexnat <tho...@alexnat.de>
Subject Major bug with cocoon views -- Using views not really possible
Date Fri, 10 Dec 2004 14:13:22 GMT
Dear Vadim,

I also think, that this behaviour is a bug. To me it renders the usage 
of the cocoon view concept absolutely useless. My major point is, that 
is, that I cannot use the cocoon views to view my current matcher in 
XML. If I try to do that, everytime I have a 'aggreate' or 'cocoon:/' 
protocol in my pipeline, the XSL scrambles the content, because 
previous matchers are also transformed. (see older mails from me)

The only workaround I currently know, is to generate the XML content in 
my own pipie -- not using views. This is not a feature to me, its more 
a big bug.

Where can I add this bug? Or to whom can I talk?

Thanks in advance,
    Thomas



On 10.12.2004, at 14:09, Vadim Gritsenko wrote:

> Sylvain Wallez wrote:
>> Thomas Alexnat wrote:
>
> <snips/>
>
>>> <map:aggregate element="categoryindexpage">
>>>    <map:part src="cocoon:/getXMLContentA"/>
>>>    <map:part src="cocoon:/getXMLContentB"/>
>>> </map:aggregate>
>>>
>>> are resulting in a corrupt XML tree after calling them with the 
>>> default pretty-print view. As expected, the pretty-view gets 
>>> pretty-printed...
>
> <snips/>
>
>> Now the question is what behaviour is to be considered "correct" 
>> regarding views and internal pipeline calls. Should we consider that 
>> view should be taken into account only for external requests?
>
> That would not be correct too, me thinks. Correct behavior would be to 
> "reset" view when making internal request, but allow requestee to 
> specify which view of internal pipeline it desires to obtain.
>
> I mean, example above should work as expected: no view label should be 
> passed to cocoon:/getXMLContentX, but view label should be passed if 
> request is made as cocoon:/getXMLContentX?cocoon-view=content.
>
> Current behavior seems like a bug, and because of this there is no 
> need to preserve it for "backward compatibility".
> ... Hmmm, interesting, when this bug was introduced? ...
>
> Vadim
>
>
Schoene Gruesse,
    Thomas



Mime
View raw message