Ugh! Everything is just working now. Both <textarea></textarea> and
<textarea/> in my document are getting output the proper way. My
memory of the exact circumstance where we were seeing the problem
before is hazy.
I'm a little annoyed that I'm coming out of this looking like an
idiot, but my program is working, XMLC is working properly, and
there's no work needed from you, so I guess all has ended well.
Thanks for writing and taking the time to support such an excellent
project.
Erik
On Apr 17, 2007, at 5:09 PM, Jacob Kjome wrote:
Quoting Erik Rasmussen <rasmussenerik@xxxxxxxxx>:
I'm using the org.enhydra.xml.io.DOMFormatter directly. I can't use
the XMLCContext because I'm not using servlets and
HttpServletRequest/
Response.
I think I figured it out. I had a stray outputOptions.setFormat
(OutputOptions.FORMAT_HTML) that I added around the time of the
upgrade to beta3. The reason that I added it might be a bug you
could fix, though.
Ahhhhh.... yes, that would probably do it. I'll have to look at the
HTMLFormatter to see how it is dealing with XHTML documents. What
I might do
is force FORMAT_XHTML when it is detected that the current document is
XML-based, causing the XMLFormatter to be used. However, the
HTMLFormatter
shouldn't be outputting <br></br> anyway. I'll try to look at it
tonight.
It's kind of like the opposite of the <br> problem. Just like how
some browsers don't handle closed <script> tags properly, a closed
<textarea> tag will be rendered as a textarea containing the rest of
the document. So there should *never* be a <textarea/> in an HTML or
XHTML document.
Could the setEnableXHTMLCompatibility() flag handle this?
Yes, it should. However, are you actually seeing this when you use
FORMAT_XHTML
(or don't specify the format explicitly and FORMAT_XHTML will get
chosen for
XHTML documents automatically). You're saying that...
this:
<textarea></textarea>
turns into this?
<textarea />
Is that right? If you can verify that, that would be helpful.
I'll test at
home tonight.
Is there even a way for a dtd to require pcdata content?
Well, any way you look at it, modifying the DTD is not a good
option. And just
because a tag is written in the short form doesn't mean it can't
hold PCDATA.
It just means that, currently, there is nothing inside the tag.
Both the long
and short form are correct. Of course some browsers don't agree,
which is why
we prefer one form over the other; hence setXHTMLCompatiblity(true).
Thanks for your help, (sorry for wasting your time)
No problem. Looks like it fettered out another issue that we can
address.
Jake
Erik
On Apr 17, 2007, at 8:11 AM, Jacob Kjome wrote:
BTW, how are you actually writing the document? Are you using
XMLCContext (this is a webapp, right)? Here's the pattern....
XMLCContext context = XMLCContext.getContext(servletObj);
//OR
//XMLCContext context = XMLCContext.getContext
(servletContextObj);
.....
....
....
org.enhydra.xml.io.OutputOptions oo =
context.createOutputOptions(req, resp, xmlObj);
oo.setEnableXHTMLCompatibility(true);
oo.setUseAposEntity(false);
oo.setOmitXMLHeader(true);
oo.setMIMEType("text/html"); //optionally override that
defined by the DOMFactory implementation
context.writeDOM(req, resp, oo, xmlObj);
I want to make sure you are using XMLC's DOM formatting and not
some other non-specialized formatter. I can't guarantee what other
formatters will output.
Jake
At 12:52 AM 4/17/2007, you wrote:
That's curious. I just tested using the HEAD (same as 2.3-beta3
plus
one or two irrelevant updates) source and I always get <br /> under
the XHTML 1.0 strict DTD and <br clear="none" /> under the XHTML
transitional DTD. I never get <br clear="none"></br>. And it's
not
just setXHTMLCompatiblity(true) that goes into choosing how the tag
is ended. My memory failed me a little bit there. Everything
appears to be working from what I can see.
Are you absolutely sure you are using 2.3-beta3? I can't seem to
reproduce <br clear="none"></br>. Can you send a source document
that contains <br />, which comes out as <br clear="none"></
br>? I'm
a bit baffled by your findings. Originally I just assumed it was a
case that I must have overlooked, but based on a review of the code
and on my testing, it seems to be accounted for and behaving
properly.
Jake
At 03:12 PM 4/16/2007, you wrote:
Dunno if it helps, but this BR breaking began after an upgrade
from
2.3-beta to 2.3-beta3.
Erik
--
You receive this message as a subscriber of the xmlc@xxxxxxxxxxxxx
mailing list.
To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
ObjectWeb mailing lists service home page: http://
www.objectweb.org/wws
--
You receive this message as a subscriber of the xmlc@xxxxxxxxxxxxx
mailing list.
To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/
wws
--
You receive this message as a subscriber of the xmlc@xxxxxxxxxxxxx
mailing list.
To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/
wws
--
You receive this message as a subscriber of the xmlc@xxxxxxxxxxxxx mailing list.
To unsubscribe:
mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
For general help:
mailto:sympa@xxxxxxxxxxxxx?subject=help
ObjectWeb mailing lists service home page:
http://www.objectweb.org/wws
| 