Thông tin tài liệu
<xsl:apply-templates/> </table> </tr> </table> </xsl:template> <xsl:template match="Room"> <tr id="{@id}" style="'background-color:white;'" onmouseover="on_mouse_over('{@id}')" onmouseout="on_mouse_out('{@id}')" onclick="on_mouse_click('{@id}')"> <td><xsl:value-of select="Name"/></td> <td align="right"><xsl:value-of select="Length"/></td> <td align="right"><xsl:value-of select="Width"/></td> <td align="right"><xsl:value-of select="Windows"/></td> <td><xsl:value-of select="Misc"/></td> </tr> </xsl:template> <xsl:template match="text( )"/> </xsl:stylesheet> Figure 9-18. Interactive SVG generated from XML 9.4.3 Discussion Prior examples focused on generating SVG from XML, while this one focuses on integrating SVG into a larger application based on other web technologies. This recipe only touches on the potential of such applications. SVG contains facilities for animation and dynamic content that, when coupled with XSLT's transformation capabilities, can lead to some impressive results. Consider the following stylesheet that is based on the graph-drawing primitives of Recipe 9.2, but allows the user to interact with the graph: <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:svg="http://www.w3.org/2000/svg" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:svgu="http://www.ora.com/XSLTCookbook/ns/svg-utils" xmlns:test="http://www.ora.com/XSLTCookbook/ns/test" exclude-result-prefixes="svgu test"> <xsl:import href="svg-utils.xslt"/> <xsl:output method="html"/> <test:data>1.0</test:data> <test:data>2.0</test:data> <test:data>3.0</test:data> <test:data>4.0</test:data> <test:data>5.0</test:data> <test:data>13.0</test:data> <test:data>2.7</test:data> <test:data>13.9</test:data> <test:data>22.0</test:data> <test:data>8.5</test:data> <xsl:template match="/"> <html> <head> <title>Interactive Bar Chart</title> <object id="AdobeSVG" classid="clsid:78156a80-c6a1-4bbf-8e6a-3cd390eeb4e2"/> <xsl:processing-instruction name="import"> <xsl:text>namespace="svg" implementation="#AdobeSVG"</xsl:text> </xsl:processing-instruction> <script><![CDATA[ function on_change (ID,VALUE) { //Get the svg doc var svgDocument = document.all.item('figure').getSVGDocument( ); //The bars id is prefixed with the context value + _bar_ + ID var barName = "interact_bar_" + ID ; var barObj = svgDocument.getElementById(barName); if (barObj != null) { barObj.setAttribute('y2', VALUE); } return true; } ]]></script> </head> <body> <div align="center"> <svg:svg width="400" height="400" id="figure"> <xsl:call-template name="svgu:bars"> <xsl:with-param name="data" select="document('')/*/test:data"/> <xsl:with-param name="width" select=" '300' "/> <xsl:with-param name="height" select=" '350' "/> <xsl:with-param name="offsetX" select=" '50' "/> <xsl:with-param name="offsetY" select=" '25' "/> <xsl:with-param name="boundingBox" select="1"/> <xsl:with-param name="max" select="25"/> <xsl:with-param name="context" select=" 'interact' "/> </xsl:call-template> </svg:svg> </div> <table border="1" cellspacing="1" cellpadding="1"> <tbody> <xsl:for-each select="document('')/*/test:data"> <xsl:variable name="pos" select="position( )"/> <xsl:variable name="last" select="last( )"/> <tr> <td>Bar <xsl:value-of select="$pos"/></td> <td> <input type="text"> <xsl:attribute name="value"> <xsl:value-of select="."/> </xsl:attribute> <xsl:attribute name="onchange"> <xsl:text>on_change(</xsl:text> <! Bars oriented upward are rotated so the ids need <! to be reversed. See svgu:bars implementation > <! for clarification. > <xsl:value-of select="$last - $pos + 1"/> <xsl:text>, this.value)</xsl:text> </xsl:attribute> </input> </td> </tr> </xsl:for-each> </tbody> </table> </body> </html> </xsl:template> </xsl:stylesheet> This stylesheet results is a web page that allows you to change data while the height of the bars responds in kind. This stylesheet also demonstrates the technique for inlining SVG content in HTML. Unfortunately, it works only with IE 5.5 or higher browsers and assumes that you use the Adobe SVG plug-in. [3] [3] This, of course, is the configuration used by a large segment of the modern world. 9.4.4 See Also Didier Martin's XML.com article Integration by Parts: XSLT, XLink and SVG (http://www.xml.com/lpt/a/2000/03/22/style/index.html) contains a more compelling example involving interaction with a CAD diagram of a complex part. J. David Eisenberg's SVG Essentials (O'Reilly, 2002) contains detailed information about SVG animation and scripting. Chapter 10. Code Generation Good programmers write good code. Great programmers write programs to generate it. —Unknown Automation is the holy grail of software development. In fact, much of the progress in software development is driven by the notion of code generation from some higher-level specification. After all, isn't that what assemblers and compilers do? However, in another form of code generation, the target language is not executable machine code, but a high-level language such as Java or C++. Why would you want to generate code in this way, and what does XML have to do with it? When you write programs, you essentially encode many kinds of knowledge into a very specific syntax that is optimized for one particular development life-cycle phase. It is difficult to leverage the work done in coding to other important development tasks because programming languages are difficult to parse and much of the interesting information is encoded in ad-hoc comments. Representing application knowledge in XML provides the opportunity for much greater leverage. From XML specifications, you can generate application code, test programs, documentation, and possibly even test data. This is not to say that XML gives you this for free. As with all software- development tasks, a great deal of planning and infrastructure building is required to reap the benefits. This chapter is different from most other chapters in this book because most examples are components of a solution within the context of a particular application. The reason for this structure is two-fold. First, it is unlikely that you would encode information in XML to generate code just because XML is cool. In most cases, a larger problem must be solved in which XML can be further leveraged. The examples in this section will make more sense if they are presented in the context of a larger problem. Second, the particular problem is common in large-scale application development, so readers might find it interesting in its own right. However, even if this is not the case, the larger problem will not take away from the application of the concepts to other development tasks. So what is this large problem? Imagine a complex client-server application. Complex means that it consists of many types of server and client processes. These processes communicate via messages using message-oriented middleware (either pointing to point, publish/subscribe, or both). IBM MQSeries, Microsoft Message Queuing (MSMQ), BEA Systems Tuxedo, and TIBCO Rendezvous are just a few of the many products in this space. In this example, the particular middleware product is not particularly relevant. What is relevant is that all significant work performed by the system is triggered by the receipt of a message and the subsequent response involving one or more messages. [1] The message may contain XML (SOAP), non-XML text, or binary data. Chapter 12 covers SOAP in the context of WSDL. This chapter is primarily interested in server-to-server communication in which XML is used less often. [1] Obviously, user input and output is also relevant. However, you can think of I/O in terms of messages.These user I/O messages are normally sent and received over different channels, though, not interprocess messages. What is particularly daunting about such complex systems is that you cannot simply understand them by viewing the source code of any one particular type of process. You must begin by first understanding the conversations or inter-process messaging protocols spoken by these processes. This chapter goes even further and states that, at a first level of approximation, the details of each individual process are irrelevant. You can simply treat each process as a black box. Then, rather than understand the hundreds of thousands of lines of code that make up the entire system, you can start by understanding the smaller set of messages that these processes exchange. Thus the question becomes, how do you go about understanding the interprocess language of a complex application? Can you go to a single place to get this information? Sadly, this is often not the case. I find that you can rarely find an up-to-date and complete specification of an application's messaging protocols. You can usually find pieces of the puzzle in various shared header files and other pieces in design documents developed over the system's life cycle, but rarely will you find a one-stop source for such vital information. And in many cases, the only truly reliable method of obtaining such information is to reverse-engineer it from the applications' source code, which is exactly what I claimed you should not have to do! Okay, so what does this problem have to do with XML, XSLT, and, in particular, code generation? You can describe the solution to this problem in terms of the need for a documentation that describes in complete detail an application's interprocess messaging structure. What kind of document should this be? Maybe the developers should maintain an MS Word document describing all the messages or, better still, a messaging web site that can be browsed and searched. Or, maybe (and you should have guessed the answer already) the information should be kept in XML! Perhaps you should generate the web site from this XML. While you're at it, maybe you should generate some of the code needed by the applications that processes these messages. This is, in fact, exactly what you shall do in this chapter. I call the set of XML files an interprocess message repository. Many recipes in this chapter demonstrate how to generate code using this repository. Before moving to the actual recipes, this chapter presents the repository's design in terms of its schema. It uses W3C XSD Schema for this purpose but only shows an intuitive graphical view for those unfamiliar with XML schema. Figure 10-1 was produced using Altova's XML Spy 4.0 (http://www.xmlspy.com). The icons with three dots ( ) represent an ordered sequence. The icon that looks like a multiway switch represents a choice. Figure 10-1. Graphical representation of XSD schema for repository Although this schema is sufficient to illustrate interesting code-generation recipes, it is probably inadequate for an industrial-strength message repository. Additional data might be stored in a message repository, as shown in the following list: • Symbolic constants used in array and string sizes, as well as enumerated values • Information about more complex data representations, such as unions and type-name aliases (C typedefs) • Information about message protocols (complex sequences of messages exchanged by sets of processes to achieve a specific functionality) • Historical information such as authors, last changed by, change dates, etc. • Delivery and transport information related to publishers and subscribers or queue names As sample repository data, imagine a simple client-server application that submits orders and cancelations for common stock. The repository for such an application might look like this: <MessageRepository xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi: noNamespaceSchemaLocation="C:\MyProjects\XSLT Cookbook\code gen\MessageRepository. xsd"> <DataTypes> <Primitive> <Name>Real</Name> <Size>8</Size> <Category>real</Category> </Primitive> <Primitive> <Name>Integer</Name> <Size>4</Size> <Category>signed integer</Category> </Primitive> <Primitive> <Name>StkSymbol</Name> <Size>10</Size> <Category>string</Category> </Primitive> <Primitive> <Name>Message</Name> <Size>100</Size> <Category>string</Category> </Primitive> <Primitive> <Name>Shares</Name> <Size>4</Size> <Category>signed integer</Category> </Primitive> <Enumeration> <Name>BuyOrSell</Name> <Enumerators> <Enumerator> <Name>BUY</Name> <Value>0</Value> </Enumerator> <Enumerator> <Name>SELL</Name> <Value>1</Value> </Enumerator> </Enumerators> </Enumeration> <Enumeration> <Name>OrderType</Name> <Enumerators> <Enumerator> <Name>MARKET</Name> <Value>0</Value> </Enumerator> <Enumerator> <Name>LIMIT</Name> <Value>1</Value> </Enumerator> </Enumerators> </Enumeration> <Structure> <Name>TestData</Name> <Members> <Member> <Name>order</Name> <DataTypeName>AddStockOrderData</DataTypeName> </Member> <Member> <Name>cancel</Name> <DataTypeName>CancelStockOrderData</DataTypeName> </Member> </Members> </Structure> <Structure> <Name>AddStockOrderData</Name> <Documentation>A request to add a new order.</Documentation> <Members> <Member> <Name>symbol</Name> <DataTypeName>StkSymbol</DataTypeName> </Member> <Member> <Name>quantity</Name> <DataTypeName>Shares</DataTypeName> </Member> <Member> <Name>side</Name> <DataTypeName>BuyOrSell</DataTypeName> </Member> <Member> <Name>type</Name> <DataTypeName>OrderType</DataTypeName> </Member> <Member> <Name>price</Name> <DataTypeName>Real</DataTypeName> </Member> </Members> </Structure> <Structure> <Name>AddStockOrderAckData</Name> <Documentation>A positive acknowledgment that order was added successfully. </Documentation> <Members> <Member> <Name>orderId</Name> <DataTypeName>Integer</DataTypeName> </Member> </Members> </Structure> <Structure> <Name>AddStockOrderNackData</Name> <Documentation>An negative acknowledgment that order add was unsuccessful. </Documentation> <Members> [...]... processing, but the processing of trees that contain text nodes As such, XSLT facilities transform trees more nimbly than Perl does Nevertheless, Perl and XSLT can team up to create a best-of-both-worlds approach, as shown in Chapter 12 Chapter 12 also presents an extension to XSLT that removes the verbosity that gets in the way of pure XSLTbased generators 10.4 Generating Data Wrappers 10.4.1 Problem You... (XMI) The second discusses using XSLT to generate XSLT Before proceeding with the actual examples, I apologize for using C++ for most of the examples I did this only because it is the language with which I am most familiar; it is the language for which I have actually written generators; and the conceptual framework is transferable to other languages, even if the literal XSLT is not.[2] [2] I am tempted... very basic example of this genre Some commercially available wizards generate the structure of entire applications It is not clear whether XSLT can scale to create wizards of that magnitude However, for simple kinds of stub generators for which the input is XML, XSLT is preferable to other languages, including Perl Many Perl fanatics disagree with this statement because they view XML processing as just... Java requires everything to live inside a class, but you can accommodate that too: ]> .xslt to customize the function > void prettyPrintMessage (ostream& stream, const Message& msg) .xslt to generate > XSLT- based generator allow you to automate the task of producing wrappers In practice, wrappers sometimes contain some smarts, and you might need to store additional metadata in the repository to get corresponding... CancelStockOrderNackData StockServer StockClient TEST 7 TestData StockServer StockClient ... create generation components that could be reused in more complex generation scenarios Here is what a generic Cswitch statement generator might look like: ]> . xmlns:svgu="http://www.ora.com/XSLTCookbook/ns/svg-utils" xmlns:test="http://www.ora.com/XSLTCookbook/ns/test" exclude-result-prefixes="svgu test"> <xsl:import href="svg-utils .xslt& quot;/>. technologies. This recipe only touches on the potential of such applications. SVG contains facilities for animation and dynamic content that, when coupled with XSLT& apos;s transformation capabilities,. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi: noNamespaceSchemaLocation="C:MyProjects XSLT Cookbook code genMessageRepository. xsd"> <DataTypes> <Primitive>
Ngày đăng: 14/08/2014, 01:20
Xem thêm: xslt cookbook phần 7 pot, xslt cookbook phần 7 pot
