Question

Developing server side code i finally got my eyes X-crossed trying to write - and then understand, of course - forms or other html code in which text strings (attributes) within double quotes must occur in tagged string (markup) opening and closing properly; but often javascript text within apostophes must be instantiated, quite often quoting other text (within quotes, of course) or instantiating computed values that must be placed within language dependent markup

This is a complete mess and a mainroad to blindness, and madness, and a sure way to waste my time tryng to figure out why the last cell in a table is rendered before the table caption - sure, I missed an apostrophe in a string of 512 characters. After trying to reinvent the wheel crafting some API to manage the unmanageable, I have seen this possible solution: well, the damned xhtml is, in facts, XML. So why not use a XMl parser (on server) to create from scratch a document fragment, populate it adding childnodes at my will, then having the parser serialize all the fragment tree taking care of the stupid details like opening and closing tag, adding the apostrophes and all the other similar stuff? Using it only in the backoffice side should keep low workload on the server - only few people in this planet could authenticate and access the serious stuff, so object creation and release is kept acceptable.

My question is: is this in your opinion a good solution to the problem mentioned above? Maybe there are simpler solutions I am neglecting? There is some problem I did not see? Is it a sort of overkill? Ironic "congrats, you finally got it" are accepted.

Thanks!

Was it helpful?

Solution

Building a DOM dynamically server-side and then dumping the resulting HTML (or XHTML) is what most serious server-side technologies do. Perhaps they don't do it with raw XML--perhaps they have their own class structure/API that they use to do this, but that's the basic paradigm they follow.

As for "congrats, you finally got it", I'd say you're on the right path. You didn't mention specific technology, but I'd guess you've been messing around with creating raw HTML using basic PHP or Perl. Congratulations, you've done what the rest of us do, eventually: wonder if there's a better way. I would suggest that you look into some of the serious web application frameworks out there, like ASP.NET MVC, Ruby on Rails, Struts, or Twisted.

OTHER TIPS

Yes, I'm using the framework's XML-related classes to parse XHTML, and to create XHTML.

I think the ironic "congrats, you finally got it" is the most appropriate answer here. XHTML is a subset of XML, so any XML tools would be able to do this properly for you, and allow you to focus on the content, not the format of the content.

Basically, there are more XML parsers and document models than you can shake a stick at. Unless you have a specific need for performance and crafting custom XML strings makes more sense to you, using one of these libraries is the best bet.

This is exactly what XSLT was invented for: transforming XML documents into XML documents without screwing anything up. Once you understand XSLT (and, regrettably, this takes some doing), the kinds of problems that are vexing you now disappear from your life completely.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top