[TFUI] Re: XML -> XSLT -> XHTML Nirvana
"Donald Roby" <donalroby-/[email protected]>
| Newsgroups | gmane.comp.programming.test-first-user-interfaces |
|---|---|
| Message-ID | <[email protected]> |
--- In [email protected], "Phlip" <phlip2005@g...> wrote: > TFUI: > > Since reading /XP for Web Projects/, I took on an in-house web site project. > Some of it was already written, so I was not able to apply WebXP's Prime > Directive everywhere. > > WebXP's Prime Directive is that all HTML in your browser must come from > XSLT, supplying markup, and XML, supplying data. The book makes a powerful > case for using that transformation as the nucleus of a build system, as an > automated site map, and as one helluva big validation test. At all times, a > web site should present no broken links or related cruft. > > To follow that directive, you always push your data into a data > representation, store this in XML, and transform it with XSLT to generate > the output HTML. WebXP implies ones entire browser experience must come > through this pipeline. > Generally good advice, but I'm not sure about this "Prime Directive" stuff. Sounds a bit too much like a rule. > I take the PD one step further, and always generate XHTML, using this > mysterious concoction in the XLST: > > <xsl:output method="xml" media-type="text/html" standalone="no" > omit-xml-declaration="yes" encoding="UTF-8" /> > > That permits XPath in the tests to query out and verify details of the > intermediate XHTML. > And that one maybe should be a rule. I can't think of a good reason for ever producing HTML that is not XHTML. And XML is much easier to test than HTML. > However, when aiming for the goal "only XSLT supplies markup", I cheat. > Faced with a short schedule and long feature list, and face with the absurd > complexities required to code a lowly 'if' statement inside XSLT, I move the > 'if' statement up into the project that generates the XML. > XSLT's 'if' all by itself isn't all that bad if the condition is simple. > So, if I want a field to optionally appear hotpink, the generating program > calls something like this (in fictitious Perl): > > set($myNode, 'my_data_name', '<span style="background-color:hotpink">my > data value</span>'); > > The intermediate XML attribute contains that snip of XHTML, escaped properly > to nest inside XML. > > Then, the XSLT turns the escapes back into HTML, using something like > <xsl:value-of disable-output-escaping="yes" select="@my_data_name"/>. > There's definitely a prettier way. In this example, you could at least stash the color in XML data with your upstream logic and then reference the data to produce that span tag in XSLT. And if there's a business reason for it to sometimes be hotpink, that fact might appropriately be considered data rather than presentation. Might want to genericize to regard highlighting as business data and choice of which color as presentation, but I still think there may be valid reasons for that decision to be done upstream. > This post is either a question or a manifesto, depending on if anyone has > read and/or followed the book more strictly than I and can raise any > objections! > Haven't read it, but I never let that stop me from raising objections. To unsubscribe, email: TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/TestFirstUserInterfaces/ <*> To unsubscribe from this group, send an email to: TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/