* Sajeesh N Kakkat <ksajeesh(_at_)in(_dot_)ibm(_dot_)com> [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(_at_)engrm(_dot_)com
- http://engrm.com/blogometer/index.html
- http://engrm.com/blogometer/rss.2.0.xml
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--