XpForWebProjects

In there they suggest using XML as the response to all server-side request processing. Then they take that XML and having one layer (they suggest XSLT layer), you mark up the XML into the HTML required.

Now this sounds quite appealing from a testing point of view in that as a programmer I don't have to worry about HTML at all. My contract with the HTML/XSLT guys is that the XML will contain all the data they need.

They argue this centralises the HTML processing, and moves HTML generation out of the programming domain. I can read XML that I create, and have it validated by my XML Schema for free. If I use JAXB or similiar then I can create Java objects and test those, knowing that I can generate the XML for these easily.

I'm no longer having to test the HTML output from my Java programs (which is very tricky to do since its fragile as hell), I've moved closer to pure testing objects. Hmmm... well I've also moved the HTML testing aswell - I haven't got rid of it. How am I going to test that the XSLT transformations are correct? Infact I don't have experience with XSLT so if there is a problem then I can't help until I've learnt it.

I have treated this book with extreme caution. It is much more prescriptive in terms of specific technologies than any of the others in the series I have read and that smells bad. Please reassure me that this is indeed the way to go...

Can I humbly suggest XmlUnit for testing your XSLT and HTML if you go down this path ;-) TimBacon

• Do your HTML designers have declarative logic skills?
• XLST is a nightmare to read and maintain, there are lots of implicit things that go on.
• All the session state has to be exploded into hidden form fields, or built into every link, then if you add a new name value pair, all the links have to "ping pong" that new field back to the servlet, so that the servlet can put it back in an XSLT variable. That all disappears up it's arse very quickly.
• Then there's getting all the escaping right, were for example entities like amperands are not escaped in XML attributes, but are escaped in XML body text, but then you have to make sure you escape things properlly in the XSLT target which is different depending on where you get things from in the XML. (AT&T are a real pain).
• Woe betide if you're data includes any entities with no declared unicode character, or the XSLT parser explodes.

The list goes on and on, with gotchas that are so far removed for putting HTML in a browser that it's ridiculous.

I never thought I'd say this, but I'd rather have people putting little bits of Java in JSP pages, than have them hacking about with XSLT templates.

UI design should not be like this, it's going in the wrong direction, you should draw what you need then mark up the dynamic bits. I'm grumpy to hear somebody has come up with XSLT as the solution for an XP approach to web design. It's not the simplest thing, and they've plainly not arrived at this conclusion from actually using it.

All my web designers have ASP skills so we're going with ASP.NET. We (the programmers) make up nice drag and drop components for them (in c#, which we can unit test as they're non visual) and then, they use data binding to plop them in pages, it's really rather neat, hat's off, it's Delphi for web pages.

We realised that our users (internal and external) are really web designers and aren't really interested in composing clever canonical classes, they just want a big mother session class that will answer all their questions. Ofcourse that class is just a delegating wrapper for a bunch of composed canonical classes.

-- OliBye

I'm gonna plug SiteMesh here... allows seperation of content/layout using existing skills (HTML). Nice and simple and no XSLT. -JoeW

³rev³8³XpForWebProject ³³date³January 11, 2003³host³³agent³Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705)³XpForWebProjects