Dear Geert,
Thanks for your reply.
Geert Josten wrote:
Hi Lars,
I have the impression that something is going wrong.
:-) Me too!
Have you checked the log files for errors?
Yes. There's nothing in the error.log corresponding to this problem. The
only hint there is that the count-rows.xsp is not compiled until I call
the count-rows URL
(http://localhost/mount/ethnologue/checks/count-rows?table=Development_Status)
directly... in other words, the cinclude transformer is not calling the
count-rows URL even though it is instructed to do so.
And what happens if you place the cincludes behind each other in stead
of inside each other?
In the input to the cinclude transformer (cocoon-view=raw), i.e. the
part that I can control, they are one-behind-the-other. It's only after
the cinclude transformer that they come out one-inside-the-other.
If you want us to look at your url, please supply a correct dns or ip
number and not just localhost.. ;-)
It would be nice if I could let everybody try it themselves, but our
project is on an intranet.
I gave the URL just to illustrate how the URL is formed.
Regards,
Lars
Cheers,
Geert
Lars Huttar wrote:
Dear Cocoonists,
We're getting strange results from cinclude. It's all the more
baffling because cinclude works fine in many cases.
FYI we've tried this with Tomcat 4.1, Tomcat 5.5, and Jetty, and
Cocoon 2.1.2, 2.1.5.1, and 2.1.7. All give the same results.
When I run the troubled URL,
"http://localhost:8888/mount/ethnologue/checks/list-tables";, the
browser gives an XML parsing error because the output from cinclude
is not well-formed XML: most elements have no close tags!
If I do a view-source on the output of the cinclud transform, it
looks like this:
<table xmlns:cinclude="http://apache.org/cocoon/include/1.0";>
<cinclude:include
src="cocoon:/checks/count-rows?table=Development_Status">
<cinclude:include
src="cocoon:/checks/count-rows?table=Development_Type">
...
<cinclude:include
src="cocoon:/checks/count-rows?table=Writing_System"/>
(That's really the end!)
Note that only the last element is closed.
The pipeline in the sitemap:
<map:match pattern="checks/list-tables">
<map:generate src="sources/ethnologue-schema.xml"/>
<!-- Generate cinclude statements for checks/count-rows from
<table> elements. -->
<map:transform src="transforms/list-tables-cinclude.xsl"
label="raw"/>
<!-- Process cinclude statements. -->
<map:transform type="cinclude" label="raw2"/>
<map:serialize type="xml"/>
</map:match>
The data in the pipeline before the cinclude transformer
(check/list-tables?cocoon-view=raw) looks like this:
<tables xmlns:cinclude="http://apache.org/cocoon/include/1.0";>
<cinclude:include
src="cocoon:/checks/count-rows?table=Development_Status"/>
<cinclude:include
src="cocoon:/checks/count-rows?table=Development_Type"/>
...
<cinclude:include
src="cocoon:/checks/count-rows?table=Writing_System"/>
</tables>
In other words, the output of the cinclude transformer is the same as
its input, except that each <cinclude:include> element becomes a
child of the previous one. Or to put it another way, all the
endElement events except one are dropped. There is no processing of
the src URLs.
Incidentally, if you run the src URLs on their own, e.g.
http://localhost/mount/ethnologue/checks/count-rows?table=Development_Status,
they run successfully and produce well-formed XML output:
<table [namespace declarations for xsp, xspdoc, esql, xsp-request]>
<name>Development Status</name>
<count>11875</count>
</table>
As I mentioned at the top, cinclude works fine for us in other
applications.
Any ideas?
One interesting thing is that if we follow the cinclude transformer
with an XSLT transformer that simply copies its input, that the XSLT
transformer's output is
<table xmlns:cinclude="http://apache.org/cocoon/include/1.0";>
<cinclude:include
src="cocoon:/checks/count-rows?table=Development_Status">
<cinclude:include
src="cocoon:/checks/count-rows?table=Development_Type">
...
<cinclude:include
src="cocoon:/checks/count-rows?table=Writing_System"/>
...
</cinclude:include>
</cinclude:include>
</table>
In other words, all the unclosed elements get closed. But still no
indication of why they became children of each other, nor why the
<cinclude:include> elements didn't get replaced with the output of
their respective src pipelines.
Any help would be appreciated...
Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
