tags:

views:

320

answers:

4

What conventions (if any) do you use for indenting XSL code?

  • how do you deal with really long, complicated XPaths
  • can you plug them into your XML editor of choice?
  • is there some open source code that does the job well?

For some background, I use nxml-mode in Emacs. For the most part its OK and you can configure the number of spaces that child elements should be indented. Its not very good though when it comes to complicated XPaths. If I have a long XPath in my code, I like to make it's structure as transparent as possible by making it look something like this...

<xsl:for-each select="/some
                       /very[@test = 'whatever']
                        /long[@another-test = perhaps
                                               /another
                                                /long
                                                 /xpath[@goes='here']]
                         /xpath"

However, I currently have to do that manually as nxml will just align it all up with the "/some.."

+1  A: 

In my opinion, long xpaths are hard to read and should be avoided. There are 2 ways to do it:

  1. Simplify the source xml.
  2. Split big templates into smaller ones.
Azat Razetdinov
A: 

I tend to break down the XSL differently if I'm having difficulty reading the xpath statements (which isn't very often, but it happens occasionally)... it's actually rather similar to my methods of breaking up syntax for other languages... So your example in the question might become something more like this:

<xsl:for-each select="/some/very[@test = 'whatever']/long">
  <xsl:if test="@another-test = perhaps/another/long/xpath[@goes='here']">
    <xsl:for-each select="xpath">
      ... result xml ....
    </xsl:for-each>
  </xsl:if>
</xsl:for-each>
Isaac Dealey
+1  A: 

Don't use long xpaths. Ditch the for-each and use match templates. Break down the xpath into several templates. It's much easier to read a bunch of trivial match templates than one of these.

Ishmael
Will this affect performance, and if does affect it, how much?
chiborg
@chiborg, most processors will compile XSL so the difference "should" be minimal. The language was built as a template matching engine, so this should be the optimal approach. Anyway, it's the only way you can learn to "think" in XSL.
Ishmael
+1  A: 

Sometimes a longer xpath can't be avoided, even if you use templates instead of for-eaches (like you should, if you can). This is especially true in XSLT/XPath 2.0:

<xsl:attribute name="tablevel" 
     select="if (following::*[self::topic | self::part]) 
             then (following::*[self::topic | self::part])[1]/@tablevel
             else @tablevel"/>

I tend not to break a "simple" path across lines, but will break the "greater" path at operators or conditionals.

For editing, I use Oxygen (which is cross-platform) and it handles this kind of spacing pretty well. Sometimes it doesn't predict what you want exactly, but it will maintain the space once it's there, even if you re-indent your code.

James Sulak
Holy yikes. I guess I'm a bit behind on the times.
Ishmael