RE: Re: How can I insert 'raw' (X|XHT|HT)ML into my DOM?

Something I have done before is to have another auxilary Document that has the 
document fragment, or fragments that I want to insert into my main DOM. When 
creating the main Document, I insert fragments from the other DOM. This allows 
you the possibility of having many variations in the dynamic data.   The 
auxilary Document may have many "<div>" elements or other block elements.  You 
can pick and choose which one(s) you need to insert into the master document. 

This may or may not apply to your situation. If the markup comes from an 
external source, then this may not work for you. 

Mike. 

-----Original Message-----
From: Richard Kunze [mailto:kunze@xxxxxxxxx]
Sent: Thursday, January 16, 2003 5:12 AM
To: xmlc@xxxxxxxxxxx
Subject: Re: Xmlc: Re: How can I insert 'raw' (X|XHT|HT)ML into my DOM?


On Thursday 16 January 2003 15:17, dcorbin@xxxxxxxxxxxxxx wrote:

> > It does if you output to XML (including XHTML, of course).
>
> So is there a frowned upon solution for XML?

No - there's nothing in the DOM API that can be "recycled" for a hack like 
CDATA sections for HTML. 

And I really don't see a need for it, either, because it's no problem to parse 
an XML "snippet" (as opposed to HTML, where it's difficult enough to parse 
complete documents, let alone snippets) into a DOM with a run-of -the-mill 
XML parser and import the resulting node tree into the main DOM.

> > In HTML, there are no CDATA sections, but sometimes the need to put
> > unescaped  markup into a DOM. What's more, the semantics of a CDATA
> > section ("leave  anything in here as is" :-) more-or-less matches the
> > intended effect of  putting chunks of verbatim markup into the
> > document. So, it was kind of  reasonable to reuse the CData support in
> > the HTML DOM to support unescaped  markup.
> >
> > BTW, here's the obligatory official frown :-) I'd strongly advise you
> > to only  use the CDATA hack if there's really no other reasonable way
> > (say, you've got  predefined markup in a legacy database or something
> > like this) because  putting raw markup into an XMLC DOM has a number of
> > disadvantages: - If you're not careful, you can easily produce
> > documents that are not valid  HTML
>
> I can easily produce invalid XML (not-DTD compliant) too.

Sure - but you can't produce XML that's not wellformed (e.g. has unabalanced 
tags) as you can with the CDATA hack.

> > - DOM access methods like Document.getElementById(),
> > Document.getLinks() etc.  don't see the elements inside a CDATA node
> > - Automatic URL rewriting doesn't work for links/forms/whatever inside
> > of a  CDATA node
>
> I have a solution that is working by generating DOM objects. But it is
> VERY complex, and am at a point where I think it will be getting even more
> complex as I go forward.

That's why the CDATA hack is in there, so go ahead and use it.

> But, the official frown is noted....

Well, it's more of a caveat that you lose a couple of nice features if you use 
the CDATA hack, actually. I just couldn't resist the temptation of the first 
sentence in the original post ("Although it's officially frowned upon, ...") 
:-)

-- 
Richard Kunze 

[ t]ivano Software, Bahnhofstr. 18, 63263 Neu-Isenburg
Tel.: +49 6102 80 99 07 - 0, Fax.: +49 6102 80 99 07 - 1
http://www.tivano.de, kunze@xxxxxxxxx 


_______________________________________________
XMLC mailing list
XMLC@xxxxxxxxxxx
http://www.enhydra.org/mailman/listinfo.cgi/xmlc