You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Robin Green <gr...@hotmail.com> on 2001/03/27 00:28:33 UTC
RE: There appears to be an XML-to- HTML formatting problem on my server...
Hello again.
"Brown III, Robert" <RB...@concord.com> wrote:
> >If cocoon can not find a cocoon-format PI; <?cocoon-format
> >type="xxx/yyy"?>
> >where xxx/yyy is a formatter in cocoon.properties; it is using the
> >default formatter as specified in cocoon.properties:
> >
> >formatter.default = text/html
>
>A couple of things:
>
>(1) I have no problem with Cocoon using the default formatter. The problem
>here is that, in the cocoon.properties file, the declaration for the header
>that should be put in for text/html is copied below:
>
># HTML 4.0 (strict)
>formatter.text/html.doctype-public = -//W3C//DTD HTML 4.0//EN
>formatter.text/html.doctype-system =
>http://www.w3.org/TR/REC-html40/strict.dtd
>
>but what is actually being put into the header is:
>
><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
> "http://www.w3.org/TR/WD-html-in-xml/DTD/xhtml1-strict.dtd">
>
>which is clearly different from the header that is declared for the default
>formatter! Unless there is something I am missing? If Cocoon is going to
>insist on using the default formatter, why isn't it pulling in the correct
>DTD???
HTML would not be the correct DTD, because you are not outputting a complete
HTML document. Right?
>(2) Please note that the XML file did, indeed, have a Cocoon formatting
>processing instruction in it (as explained in my original message):
>
><?cocoon-format type="text/html/loose"?>
>
>which is intended to make Cocoon use the following from the
>cocoon.properties file:
>
># HTML 4.0 (transitional)
>formatter.text/html/loose.doctype-public = -//W3C//DTD HTML 4.0
>Transitional//EN
>formatter.text/html/loose.doctype-system =
>http://www.w3.org/TR/REC-html40/loose.dtd
>formatter.text/html/loose.preserve-space = true
>formatter.text/html/loose.encoding = UTF-8
>formatter.text/html/loose.indent = 1
>formatter.text/html/loose.line-width = 120
>formatter.text/html/loose.MIME-type = text/html
>
>Note that, in addition, I added the following to my .XSL file, as indicated
>by the FAQ:
>
> <xsl:template match="cocoon-format()">
> <xsl:copy-of select="."/>
> </xsl:template>
That should be
<xsl:template match="processing-instruction()">
<xsl:copy-of select="."/>
</xsl:template>
In future, I suggest you check your XSLT is conformant against the spec at
w3.org before assuming that there must be a Cocoon bug.
>(3) What I am trying to do is output XML.
Then why don't you use <?cocoon-format type="text/xml"?> ?
>What I am *really* doing is trying
>to get an Xalan servlet example to work on a system that happens to have
>Cocoon on it. I am finding some weird interactions between servlets that
>use
>Xalan and Cocoon.
Cocoon 1 is not _designed_ to interact with other servlets (and I stress the
word designed). That doesn't mean it can't, in fact it works rather well for
some people, it just means there are a number of problems, some of which are
well-known and can be worked around. Cocoon 2 will be slightly better with
its content aggregation etc.
>This info, however, is FYI; the problems I am having can
>be solved if Cocoon wouldn't keep putting in that reference to a
>nonexistent
>DTD, so that is the thing I am trying to fix.
Then use <?cocoon-format type="text/xml"?> That will remove the DTD
entirely.
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
'socket write error - connection was reset by peer', servlet is invoked twice, though requested once
Posted by Gritsenko <vg...@acm.org>.
My servlet takes HTTPRequest and collects data in set of nested JavaBean
Value Objects using reflection,
then it takes nested Value Object and produces JDOM XML using reflection,
then it invokes Cocoon 1.8.2 engine to handle my Request with XML String and
my Response.
Explorer 5 shows PDF with no visible problem,
but I can see a message in JVM console:
'socket write error - connection was reset by peer'.
When tested from behind a firewall and with rather strong IExplorer security
settings, I notice that my servlet is invoked once, then JVM console tells
that PDF is rendered successfully, but browser does not receive it, and
suddenly Servlet is invoked second time.
What can that mean?
Netscape 4.5 doesn't even show HTML page, but that's because it has 3 levels
of nesting tables to show hierarchy.
If you have other version of NEtscape than 4.51, can you see the following,
if yes, does hit on Print button result in PDF?
http://cr723247-a.slnt1.on.wave.home.com:8080/jawebo/opano/view_update.jsp
Viktor Gritsenko
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: There appears to be an XML-to- HTML formatting problem on my
server...
Posted by Uli Mayring <ul...@denic.de>.
On Mon, 26 Mar 2001, Robin Green wrote:
> Cocoon 1 is not _designed_ to interact with other servlets (and I stress the
> word designed). That doesn't mean it can't, in fact it works rather well for
> some people, it just means there are a number of problems, some of which are
> well-known and can be worked around. Cocoon 2 will be slightly better with
> its content aggregation etc.
Just slightly? :)
Anyway, there will be a new way for servlets (or other programs) to
interact with Cocoon. I am in the process of rewriting my SOAP taglib and
with the new version it will be possible to use Cocoon via SOAP. Now,
don't get your hopes up too high, my design is terribly complicated and
inelegant. "Release early, release often" means that at first it sucks. In
fact I don't like it a bit, but miraculously it does work and makes it
very easy to integrate Cocoon in a SOAP workflow - once you get the whole
shebang installed, configured and debugged, that is. If you think
debugging Cocoon is hard, then just wait till you have to debug Cocoon
running in a SOAP workflow over the Internet :)
It's just a rope over the abyss currently, but I already have a million
ideas on how to make it better. If there's anyone interested in Cocoon and
SOAP on this list, I'd like to hear what you think. How would you
integrate Cocoon in a SOAP workflow?
Would you aim to install Cocoon itself as a SOAP service? Or would you
have all your SOAP services use Cocoon? This question means: who is the
"helper application"?
If you run Cocoon as a SOAP service:
- you'll call Cocoon from your servlets/programs, but they have to be
SOAP-aware, i.e. you have to load the SOAP libraries to communicate with
Cocoon
- you'll get XML from Cocoon, not HTML, WML, PDF or any other of the
niceties Cocoon offers. Of course you can run the XML through a local
Cocoon :)
- you write the frontend yourself (your servlets calling Cocoon are the
frontend) and don't need a local Cocoon to provide it
- Cocoon is the helper application, your servlets invoke it
If you have your SOAP services use Cocoon:
- you'll just have to make a Http connection and don't worry about SOAP
libraries and APIs
- you'll get from Cocoon whatever it can deliver
- you'll write your frontend using a local Cocoon using the SOAP taglib
- your servlets have to be rewritten as SOAP services and are the helper
applications, they are invoked via Cocoon and can in turn themselves
invoke Cocoon
Ulrich
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>