Re: XSLT Design

* 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