You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Thomas Alexnat <th...@alexnat.de> on 2004/12/07 20:45:38 UTC
Issue with cocoon views -- Bug or correct Design?
Dear Developers,
I was asking in the cocoon user mailing list why my content is not
being transformed correctly, when using the cocoon default pretty-print
view. The answers so far pointed me to the developer list, because
there seems to be a misbehaviour or misunderstanding in using the
cocoon views concept.
P R O B L E M
-------------
When calling a simple aggregated xml with the standard cocoon pretty
print view, it seems that cocoon calls the view transformer twice and
scrambles totally the output.
http://localhost:8888/a?cocoon-view=pretty-content (works fine)
http://localhost:8888/b?cocoon-view=pretty-content (scrambles xml tree,
calls the view xslt twice!)
Q U E S T I O N
---------------
How can I correctly get a view of the "b" matcher, by not scrambling
the previous included content from "a". Defining a seperate label for
each matcher does not seem to be a good and generic solution.
C O D E
-------
-- test.xml --
<test>
Hello World XML
</text>
-- sitemap.xmap -- (added to the original sitemap)
<map:pipeline>
<map:match pattern="a">
<map:generate src="test.xml"/>
<map:serialize/>
</map:match>
</map:pipeline>
<map:pipeline>
<map:match pattern="b">
<map:generate src="cocoon:/a" />
<map:serialize/>
</map:match>
</map:pipeline>
S Y S T E M
-----------
Mac OS X 10.3.6 with Cocoon 2.1.6, Dual G5, Java 1.4.2_05
Best regards and any help wanted,
Thomas
Re: Major bug with cocoon views -- Using views not really possible
Posted by Ralph Goers <Ra...@dslextreme.com>.
Joerg Heinicke said:
> On 10.12.2004 15:13, Thomas Alexnat wrote:
>> Where can I add this bug? Or to whom can I talk?
>
> You are already talking to *us*, the Cocoon community. Though there are
> people who know more about the internals of Cocoon (sitemap, request
> processing) it is always a community thing and most of committers will
> read this list and so know about this issue. You might add it to
> bugzilla though so that it won't get forgotten. But there is no
> guarantee to get it fixed quickly.
Although it helps when a patch is provided!
Re: Major bug with cocoon views -- Using views not really possible
Posted by Thomas Alexnat <th...@alexnat.de>.
Thank you -- I have submitted a new "ugreport (#32650) hope this will
be fixed anytime... ;)
On 10.12.2004, at 18:33, Joerg Heinicke wrote:
> On 10.12.2004 15:13, Thomas Alexnat wrote:
>
>> 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?
>
> You are already talking to *us*, the Cocoon community. Though there
> are people who know more about the internals of Cocoon (sitemap,
> request processing) it is always a community thing and most of
> committers will read this list and so know about this issue. You might
> add it to bugzilla though so that it won't get forgotten. But there is
> no guarantee to get it fixed quickly.
>
> Joerg
>
>
Re: Major bug with cocoon views -- Using views not really possible
Posted by Joerg Heinicke <jo...@gmx.de>.
On 10.12.2004 15:13, Thomas Alexnat wrote:
> 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?
You are already talking to *us*, the Cocoon community. Though there are
people who know more about the internals of Cocoon (sitemap, request
processing) it is always a community thing and most of committers will
read this list and so know about this issue. You might add it to
bugzilla though so that it won't get forgotten. But there is no
guarantee to get it fixed quickly.
Joerg
Major bug with cocoon views -- Using views not really possible
Posted by Thomas Alexnat <th...@alexnat.de>.
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
Re: Issue with cocoon views -- Using views to debug not really possible?
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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
Re: Issue with cocoon views -- Using views to debug not really possible?
Posted by Thomas Alexnat <th...@alexnat.de>.
Joerg,
thank you for your response. It seems that my problem seems not to be
solved with the current version of cocoon. Is this correct? I am
wondering if this is a bug or a feature. As a cocoon user I would say
this is a MAJOR bug in the view concept or implementation. Should I add
this bug to the bugtracker?
Cheers,
Thomas
On 08.12.2004, at 21:18, Joerg Heinicke wrote:
> On 08.12.2004 11:38, Sylvain Wallez wrote:
>
>> Ok, so "cocoon:raw" behaves exaclty as the regular "cocoon:"
>> regarding views.
>>> QUESTION
>>> --------
>>> What could be the best practice, if I want to look at the XML of a
>>> certain pipeline, before its transformation is being called? All I
>>> need is a good debugger view for any matcher. I am just wondering
>>> why nobody else had this same issue before...
>> The answer with the current view handling is to only use view with
>> "final" pipelines, i.e. ones that don't rely on "cocoon:" URLs.
>> 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?
>
> The current behaviour makes no sense as you can not specify
> views/labels on the pipeline, but also on the components. Thomas' use
> case already shows this leads to stupid behaviour as the duplicate
> usage of a component with @label leads to duplicate usage of view pipe
> components.
>
> IIRC this behaviour also was different, wasn't it? Wasn't only the
> last view taken into account if it is multiple times in a pipeline?
> Why should this behaviour different if an internal pipeline is
> involved? I would not restrict the usage to external requests as we
> might break usages of that "feature" - if it is implementable
> otherwise.
>
> Joerg
>
>
Schoene Gruesse,
Thomas
Re: Issue with cocoon views -- Using views to debug not really possible?
Posted by Joerg Heinicke <jo...@gmx.de>.
On 08.12.2004 11:38, Sylvain Wallez wrote:
> Ok, so "cocoon:raw" behaves exaclty as the regular "cocoon:" regarding
> views.
>
>> QUESTION
>> --------
>> What could be the best practice, if I want to look at the XML of a
>> certain pipeline, before its transformation is being called? All I
>> need is a good debugger view for any matcher. I am just wondering why
>> nobody else had this same issue before...
>
> The answer with the current view handling is to only use view with
> "final" pipelines, i.e. ones that don't rely on "cocoon:" URLs.
>
> 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?
The current behaviour makes no sense as you can not specify views/labels
on the pipeline, but also on the components. Thomas' use case already
shows this leads to stupid behaviour as the duplicate usage of a
component with @label leads to duplicate usage of view pipe components.
IIRC this behaviour also was different, wasn't it? Wasn't only the last
view taken into account if it is multiple times in a pipeline? Why
should this behaviour different if an internal pipeline is involved? I
would not restrict the usage to external requests as we might break
usages of that "feature" - if it is implementable otherwise.
Joerg
Re: Issue with cocoon views -- Using views to debug not really possible?
Posted by Sylvain Wallez <sy...@apache.org>.
Thomas Alexnat wrote:
> Dear Sylvain,
>
> thank you for your help. I have tested your idea, with a simple
> content aggregation and both variants do not show the correct xml tree:
>
> <map:aggregate element="categoryindexpage">
> <map:part src="cocoon:/getXMLContentA"/>
> <map:part src="cocoon:/getXMLContentB"/>
> </map:aggregate>
>
> or
>
> <map:aggregate element="categoryindexpage">
> <map:part src="cocoon:raw:/getXMLContentA"/>
> <map:part src="cocoon:raw:/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...
Ok, so "cocoon:raw" behaves exaclty as the regular "cocoon:" regarding
views.
> QUESTION
> --------
> What could be the best practice, if I want to look at the XML of a
> certain pipeline, before its transformation is being called? All I
> need is a good debugger view for any matcher. I am just wondering why
> nobody else had this same issue before...
The answer with the current view handling is to only use view with
"final" pipelines, i.e. ones that don't rely on "cocoon:" URLs.
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?
What do people think?
Sylvain
PS: Thomas, no need to cc me privately, I'm a careful reader of this
list, especially follow-ups to my posts.
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Issue with cocoon views -- Using views to debug not really possible?
Posted by Thomas Alexnat <th...@alexnat.de>.
Dear Sylvain,
thank you for your help. I have tested your idea, with a simple content
aggregation and both variants do not show the correct xml tree:
<map:aggregate element="categoryindexpage">
<map:part src="cocoon:/getXMLContentA"/>
<map:part src="cocoon:/getXMLContentB"/>
</map:aggregate>
or
<map:aggregate element="categoryindexpage">
<map:part src="cocoon:raw:/getXMLContentA"/>
<map:part src="cocoon:raw:/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...
QUESTION
--------
What could be the best practice, if I want to look at the XML of a
certain pipeline, before its transformation is being called? All I need
is a good debugger view for any matcher. I am just wondering why nobody
else had this same issue before...
Any comments wanted,
Thomas
PS: OS X and G5 rock!
On 07.12.2004, at 21:37, Sylvain Wallez wrote:
> Thomas Alexnat wrote:
>
>> Dear Developers,
>>
>> I was asking in the cocoon user mailing list why my content is not
>> being transformed correctly, when using the cocoon default
>> pretty-print view. The answers so far pointed me to the developer
>> list, because there seems to be a misbehaviour or misunderstanding in
>> using the cocoon views concept.
>>
>>
>> P R O B L E M
>> -------------
>> When calling a simple aggregated xml with the standard cocoon pretty
>> print view, it seems that cocoon calls the view transformer twice and
>> scrambles totally the output.
>>
>> http://localhost:8888/a?cocoon-view=pretty-content (works fine)
>> http://localhost:8888/b?cocoon-view=pretty-content (scrambles xml
>> tree, calls the view xslt twice!)
>>
>>
>> Q U E S T I O N
>> ---------------
>> How can I correctly get a view of the "b" matcher, by not scrambling
>> the previous included content from "a". Defining a seperate label for
>> each matcher does not seem to be a good and generic solution.
>>
>>
>> C O D E
>> -------
>>
>> -- test.xml --
>> <test>
>> Hello World XML
>> </text>
>>
>>
>> -- sitemap.xmap -- (added to the original sitemap)
>> <map:pipeline>
>> <map:match pattern="a">
>> <map:generate src="test.xml"/>
>> <map:serialize/>
>> </map:match>
>> </map:pipeline>
>> <map:pipeline>
>> <map:match pattern="b">
>> <map:generate src="cocoon:/a" />
>
>
> Have you tried src="cocoon:raw:/a" here? "cocoon:raw" creates a new
> "naked request" where the parameters of the original request are
> ommitted, and maybe resets the view also (although I'm not sure after
> a quick look at EnvironmentWrapper).
>
> Otherwise, the view is called twice, and the result is the
> pretty-printing of the pretty-printed version of "test.xml".
>
>> <map:serialize/>
>> </map:match>
>> </map:pipeline>
>
>>
>>
>> S Y S T E M
>> -----------
>> Mac OS X 10.3.6 with Cocoon 2.1.6, Dual G5, Java 1.4.2_05
>
>
> Wow, dual G5? Cool...
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>
>
Re: Issue with cocoon views -- Bug or correct Design?
Posted by Sylvain Wallez <sy...@apache.org>.
Thomas Alexnat wrote:
> Dear Developers,
>
> I was asking in the cocoon user mailing list why my content is not
> being transformed correctly, when using the cocoon default
> pretty-print view. The answers so far pointed me to the developer
> list, because there seems to be a misbehaviour or misunderstanding in
> using the cocoon views concept.
>
>
> P R O B L E M
> -------------
> When calling a simple aggregated xml with the standard cocoon pretty
> print view, it seems that cocoon calls the view transformer twice and
> scrambles totally the output.
>
> http://localhost:8888/a?cocoon-view=pretty-content (works fine)
> http://localhost:8888/b?cocoon-view=pretty-content (scrambles xml
> tree, calls the view xslt twice!)
>
>
> Q U E S T I O N
> ---------------
> How can I correctly get a view of the "b" matcher, by not scrambling
> the previous included content from "a". Defining a seperate label for
> each matcher does not seem to be a good and generic solution.
>
>
> C O D E
> -------
>
> -- test.xml --
> <test>
> Hello World XML
> </text>
>
>
> -- sitemap.xmap -- (added to the original sitemap)
> <map:pipeline>
> <map:match pattern="a">
> <map:generate src="test.xml"/>
> <map:serialize/>
> </map:match>
> </map:pipeline>
> <map:pipeline>
> <map:match pattern="b">
> <map:generate src="cocoon:/a" />
Have you tried src="cocoon:raw:/a" here? "cocoon:raw" creates a new
"naked request" where the parameters of the original request are
ommitted, and maybe resets the view also (although I'm not sure after a
quick look at EnvironmentWrapper).
Otherwise, the view is called twice, and the result is the
pretty-printing of the pretty-printed version of "test.xml".
> <map:serialize/>
> </map:match>
> </map:pipeline>
>
>
> S Y S T E M
> -----------
> Mac OS X 10.3.6 with Cocoon 2.1.6, Dual G5, Java 1.4.2_05
Wow, dual G5? Cool...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }