[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/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.