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
