Subject: Re: [xsl] XSLT Design From: Alan <alan-xsl-list@xxxxxxxxx> Date: Thu, 18 Aug 2005 07:08:56 -0400 |
* Sajeesh N Kakkat <ksajeesh@xxxxxxxxxx> [2005-08-18 06:01]: > This should be for single transformation using a XML file with XSLT 1 or 2 > to produce a PDF file. > > Design Patterns : > > Are there specific design patterns or ideas on how to structure XSLT code > such as to make them more readable and maintainable. This can be a problem > since both the formatting code and logic code can get intertwined in the > file and can get messy if somebody is continuously making changes on top of > it. XSLT is not my main focus, so I've not had the experience that would allow me to devine the best practices in XSLT program organization. Whenever I code XSLT, I create a new little mess. I'm very interested to hear what people come up with here. Here's some of the things I've tried to structure XSLT. 1) Pipelines I take a transform task and break it up into intermedate document formats. This breaks the task up into separate transforms. The transforms stay somewhat small. To pipeline I use Relay, a pipeline engine I wrote for myself, micro-pipelines in XSLT 2.0, or even Ant, generating temp files. For example... I'm using XML to generate JUnit tests. I want the resulting Java to be property indented so it makes sense when I step through it in a debugger. I create one transform that generates a description of the Java file that looks like so... <line>public void testFoo()</line> <line>{</line> <indent> <line>assertTrue(Boolean.TRUE.booleanValue())</line> </indent> <line>}</line> It's much easier to focus on the Java code generation separately from the text formatting. Also, there are cases where a template that generates a test may have a dependency. It can emit a tags like so.. <import>java.util.ArrayList</import> ..and if a dozen tests require the same import, I can reduce that to one import in the Java formatting stage. Also, with this sepration, I'll have a transform that can be used independently of JUnit. 2) Import If there is a method or library of methods that is at all complicated, I create a separate file. Even if that file is useless as a sole import, or useless outside of the context of the one and only transform that imports it. It's program organization only. In that file I usually create a namespace for functions and modes that should not be visible outside the file. 3) Namespaces I create namespaces. I create throwaway namepsaces. Every mode has a namespace. I never use an unqualified name to name a mode. Anyone have any thoughts on these my guidelines? > Design documents : > Are there any standard templates for writiing External design document and > internal design document for XSLT. The idea is to write whatever is being > read from the XML such as its understandable to a layman. I don't know. Another reason why my XSLT gets messy. Is there an XSLT archive network that has more than just snippits? A place where an enterprising programmer can perform code reads? -- Alan Gutierrez - alan@xxxxxxxxx - http://engrm.com/blogometer/index.html - http://engrm.com/blogometer/rss.2.0.xml
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XSLT Design, Mukul Gandhi | Thread | [xsl] Annoying XSLT code, andrew welch |
[xsl] Annoying XSLT code, andrew welch | Date | Re: [xsl] Annoying XSLT code, Alan |
Month |