|
|
I recently answered a question on a popular programmers forum about how to store and access an array of user-defined variables in a stylesheet and then loop though those variables. I realized that many developers are not familar with the available techniques for doing this and decided to add an entry in my blog about this topic.
User-defined variable arrays within stylesheets are not part of the XSLT specification. The usual way to handle this problem in XSLT 1.0 stylesheets is to define a user-defined top-level element which belongs to a non-null namespace which is different from the XSLT namspace. These user-defined top-level elements are typically used to store error messages, lookup data, etc. You can then access these user-defined elements from within your stylesheet by treating the stylesheet as an additional source document and loading it using the document() function with an empty string as the first argument. An empty string is interpreted to mean the current stylesheet.
The following stylesheet demonstrates this method. <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" xmlns:foo="http://foo.com" exclude-result-prefixes="foo"> <xsl:output method="text" encoding="utf-8"/> <foo:vars> <foo:var name="z1">A</foo:var> <foo:var name="z2">B</foo:var> <foo:var name="z3">C</foo:var> <foo:var name="z4">D</foo:var> </foo:vars> <xsl:template match="/"> <xsl:for-each select="document(”)/xsl:stylesheet/foo:vars/foo:var" > <xsl:value-of select="." /> <xsl:if test="position() != last()"> <xsl:text>,</xsl:text> </xsl:if> </xsl:for-each> <xsl:text> </xsl:text> </xsl:template> </xsl:stylesheet>
If you are using XSLT 2.0, this method is no longer needed as simpler and more elegant methods are available to us. For example, you can store and directly access the variables using the <xsl:variable> element as shown in the following stylesheet. <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0" > <xsl:output method="text" encoding="utf-8"/> <xsl:variable name="z1" select="’A'" /> <xsl:variable name="z2" select="’B'" /> <xsl:variable name="z3" select="’C'" /> <xsl:variable name="z4" select="’D'" /> <xsl:variable name="vars" select="$z1, $z2, $z3, $z4" /> <xsl:template match="/"> <xsl:for-each select="$vars" > <xsl:value-of select="." /> <xsl:if test="position() != last()"> <xsl:text>,</xsl:text> </xsl:if> </xsl:for-each> <xsl:text> </xsl:text> </xsl:template> </xsl:stylesheet>
Another way to store and access this data in a XSLT 2.0 stylesheet is to use a global variable definition as shown below. <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0" > <xsl:output method="text" encoding="utf-8"/> <xsl:variable name="vars"> <var name="z1">A</var> <var name="z2">B</var> <var name="z3">C</var> <var name="z4">D</var> </xsl:variable> <xsl:template match="/"> <xsl:for-each select="$vars/var" > <xsl:value-of select="." /> <xsl:if test="position() != last()"> <xsl:text>,</xsl:text> </xsl:if> </xsl:for-each> <xsl:text> </xsl:text> </xsl:template> </xsl:stylesheet>
All three stylesheets output the same data.
You may be wondering about this image. It is from the screen of my laptop. I used xsltproc on Microsoft Vista SUA for the XSLT 1.0 transformation and Saxon 9 in Microsoft Powershell v2.0 CTP2 for the two XSLT 2.0 transformations.
Note that the
Today, I added a gadget to my blog so that readers can easily translate my posts into any one of thirty five languages using the Google Translate webpage language translation engine. You will find it low on the left hand side of this webpage. From the drop down list, just pick the language you want to convert the current post to and after a short delay a new webpage will appear with the post displayed in the selected language. Note – you need to have scripts enabled in your browser for the Google gadget to display on this webpage.
Adding this functionality was more challanging than I initially assumed since I wanted to ensure that my posts remained useful to a reader when displayed in a foreign language. This means that the translation engine needs to be told what words and sections to leave alone as is. The Google documentation and FAQ for this gadget are unclear about how to do this for things like my display boxes so a round of experimentation was required. It turns out that you can mark a entire webpage, a word or a section of a webpage as not to be translated using the follows tags. <!– use meta element to protect entire webpage –> <meta name=’google’ value=’notranslate’> <!– use span element to protect a word or two –> <span class=’notranslate’>Do not translate these words</span> <!– use div element to protect display boxes such this –> <div class=’notranslate’>Do not translate entire section</div>
Now that I have figured out how to protect specific text and code snippets from being translated by the Google translation engine, I plan to go back and modify my previous posts over a period of time to make them more robust for automated language translation.
This will be quite a project as I typically include a number of programming langauge reserved words and code snippets in my posts. For example, it required over 100 edits to my previous post on Microsoft’s Powershell before I was happy that that particular post was suitable for automated language translation.
UPDATE 7/1/2009 This post was written when I was using Blogspot. I have not yet decided how to implement machine translation of my posts on blog.fpmurphy.com. However I do plan to implement something soon.
Microsoft’s PowerShell is radically different than shells on UNIX or GNU Linux systems in that Powershell can deal in objects rather than just plain text.
A concrete example may help you more quickly understand the difference. Suppose you want to get and save information about all the files in a certain subdirectory. We want to get not only the names of the files but as much metadata as possible relating to each file such as date of creation, date of modification, etc. This information also needs to be stored in a single XML document. To keep the size of this post manageable, our subdirectory contains only two files, i.e. file.xml and file.xsl, as shown below.
On a UNIX or GNU Linux system, this would be a somewhat difficult task to quickly accomplish. Using Powershell, however, it becomes a simple one or two line task.
Because Powershell is fundamentally object-orientated, it regards a filesystem as being an object representated as a location exposed by provider. More generally, a location can be a file directory, a registry hive, a certificate store or some other “thing” exposed by a provider. The Powershell get-childItem cmdLet is used to retrieve information, including metadata, about items in a specified location. Thus get-childItem can be used for a lot of different types of operations including enumerating directory contents, listing registry values or showing the current values of variables. For our purposes, get-childItem exposes information about files in a specified subdirectory or the current directory if no directory is specified.
Here is a single line Powershell script which does what we want to do. It retrieves metadata about the two files in the current directory using the get-childItem cmdLet, pipes that data to a cmdLet called ConvertTo-XML which in turn converts the metadata into a valid XML document. The save method is then used to write this stream out to a file called file.out in the current directory. (get-childItem | ConvertTo-XML -NoTypeInformation).save(“$(convert-path “X:”)\file.out”)
Alternatively, we could store the retrieved metadata in a variable and then write it out to a file as shown below. Similar to bash and ksh93, Powershell supports the concept of aliases and defines ls as one of the aliases for the get-childItem cmdLet,dir and gci being the other two. $a=(ls | ConvertTo-XML) $a.save(“$(convert-path “X:”)\file.out”)
Here is the contents of file.out. As you can see, quite a bit of information about each of the two files is exposed. <?xml version="1.0"?> <Objects> <Object Type="System.IO.FileInfo">
To anybody who has received formal software enginnering training, the name Grady Booch is instantly recognizable for his work and influence on software architecture, software engineering, and modeling.
He was an early advocate of formal software engineering, object orientated design and what we know today as software patterns. The Booch Method, which he detailed in his book Object Oriented Analysis and Design is an object modeling language and software development methodology that was widely used in object-oriented analysis. Along with with Ivar Jacobson and James Rumbaugh, he co-developed version 1.0 of the Unified Modeling Language.
Unless you are a member of the IEEE Computer Society, you are probably unaware the he recently recorded his On Architecture columns from IEEE Software as podcasts which are available for free download here .
So far there are 7 podcasts online; the latest being “The Irrelevance of Architecture.” I don’t know how long they will be available for downloading but this is your chance to hear one of the greats talk about software architecture and development methodology.
I am excited about the emminent release of Microsoft Windows Powershell Version 2 CTP3 (Community Technology Preview Version 3) which is due “real soon now.” The first CTP for Powershell 2.0 was in November 2007 and there has been a lot of progress on the product since then. See the permanant link at the side of my blog to access the Powershell developers blog.
Why am I, a UNIX/Linux developer, excited by Powershell V2? After all it does not run on any UNIX or GNU Linux platform and microsoft has no plans to port itMto these platforms. The main reason is that Powershell V2 supports non-compiled functions (known as script cmdlets) in scripts just like bash or ksh93 does while providing deep object orientated interfaces to the operating system and underlying platform. Previously cmdlets had to be written in a compiled language such as C# or VB.NET in order to provide such functionality. (Currently, the terminology for what is generally know as a function in a UNIX/GNU Linux shell script is called a script cmdlet in Powershell but this is apparantly on track to change to function in CTP3.) Another reason is the introduction of a graphic interface to Powershell.
I have spend more than 25 years of my life working on or with UNIX, UNIX-like or GNU/Linux operating systems. For a period of that time, I was responsible for maintenance and enhancement of various shells and hence still maintain an interest in this area. Much progress has occured in UNIX/GNU Linux shells over that period of time with bash, zsh and ksh93 emerging as the de facto leaders and csh, tcsh, sh (as in the Steve Bourne shell) and ash slowly fading away into obscurity.
Standardization of functionality for portable shell scripts has moved from simply “use the Bourne shell if you want your script to run everywhere” to written specifications such as POSIX which all three shells support. Numerious attempts (dtksh, Wksh, tksh come to mind) have been made to develop shells with graphical interfaces but none has been really successful. Currently work is afoot to provide deeper interfaces into the operating system and platform with the latest versions of ksh93 having support for compiled builtins, compound variables and quasi-objects (which I plan to write about soon in another post.)
While it may be tantamount to heresy to say this, but kudos to the Microsoft Powershell development team who have managed in my opinion to leapfrog all the
|
|
