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.

I do this too. It's definately a great XMLC pattern. "Someone" needs to
write up all the good Xmlc Patterns....   But, it doesn't help in this
situation.  What I'm doing is very wiki-like.  I've got a big string of
text, that is being converted into (X)HTML.  It's not that I can't build a
DOM by parsing this text bit-by-bit.  It's jut that's a real pain to do
so, where as doing a lot of regularExpression substitution looks very
simple.

>
> 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
>
> _______________________________________________
> XMLC mailing list
> XMLC@xxxxxxxxxxx
> http://www.enhydra.org/mailman/listinfo.cgi/xmlc