The user interface has been simplified in Dreamweaver CC and later. As a result, you may not find some of the options described in this article in Dreamweaver CC and later. For more information, see this article.
Extensible Markup Language (XML) is a language that lets you structure information. Like HTML, XML lets you structure your information using tags, but XML tags are not predefined as HTML tags are. Instead, XML lets you create tags that best define your data structure (schema). Tags are nested within others to create a schema of parent and child tags. Like most HTML tags, all tags in an XML schema have an opening and closing tag.
The following example shows the basic structure of an XML file:
<?xml version=“1.0”> <mybooks> <book bookid=“1”> <pubdate>03/01/2004</pubdate> <title>Displaying XML Data with Adobe Dreamweaver</title> <author>Charles Brown</author> </book> <book bookid=“2”> <pubdate>04/08/2004</pubdate> <title>Understanding XML</title> <author>John Thompson</author> </book> </mybooks>
In this example, each parent <book> tag contains three child tags: <pubdate>, <title>, and <author>. But each <book> tag is also a child tag of the <mybooks> tag, which is one level higher in the schema. You can name and structure XML tags in any way, provided that you nest tags accordingly within others, and assign each opening tag a corresponding closing tag.
XML documents do not contain any formatting—they are simply containers of structured information. Once you have an XML schema, you can use the Extensible Stylesheet Language (XSL) to display the information. In the way that Cascading Style Sheets (CSS) let you format HTML, XSL lets you format XML data. You can define styles, page elements, layout, and so forth in an XSL file and attach it to an XML file so that when a user views the XML data in a browser, the data is formatted according to whatever you’ve defined in the XSL file. The content (the XML data) and presentation (defined by the XSL file) are entirely separate, providing you with greater control over how your information appears on a web page. In essence, XSL is a presentation technology for XML, where the primary output is an HTML page.
Extensible Stylesheet Language Transformations (XSLT) is a subset language of XSL that actually lets you display XML data on a web page, and “transform” it, along with XSL styles, into readable, styled information in the form of HTML. You can use Dreamweaver to create XSLT pages that let you perform XSL transformations using an application server or a browser. In a server-side XSL transformation, the server does the work of transforming the XML and XSL, and displaying it on the page. In a client-side transformation, a browser (such as Internet Explorer) does the work.
The approach you ultimately take (server-side transformations versus client-side transformations) depends on what you are trying to achieve as an end result, the technologies available to you, the level of access you have to XML source files, and other factors. Both approaches have their own benefits and limitations. For example, server-side transformations work in all browsers while client-side transformations are restricted to modern browsers only (Internet Explorer 6, Netscape 8, Mozilla 1.8, and Firefox 1.0.2). Server-side transformations let you display XML data dynamically from your own server or from anywhere else on the web, while client-side transformations must use XML data that is locally hosted on your own web server. Finally, server-side transformations require that you deploy your pages to a configured application server, while client-side transformations only require access to a web server.
For a tutorial about understanding XML, see www.adobe.com/go/vid0165.
Dreamweaver provides methods for creating XSLT pages that let you perform server-side XSL transformations. When an application server performs the XSL transformation, the file containing the XML data can reside on your own server, or anywhere else on the web. Additionally, any browser can display the transformed data. Deploying pages for server-side transformations, however, is somewhat complex, and requires that you have access to an application server.
When working with server-side XSL transformations, you can use Dreamweaver to create XSLT pages that generate full HTML documents (entire XSLT pages), or XSLT fragments that generate a portion of an HTML document. An entire XSLT page is similar to a regular HTML page. It contains a <body> tag and a <head> tag, and lets you display a combination of HTML and XML data on the page. An XSLT fragment is a piece of code, used by a separate document, that displays formatted XML data. Unlike an entire XSLT page, it is an independent file that contains no <body> or <head> tag. If you want to display XML data on a page of its own, you would create an entire XSLT page, and bind your XML data to it. If, on the other hand, you wanted to display XML data in a particular section of an existing dynamic page—for example, a dynamic home page for a sporting goods store, with sports scores from an RSS feed displayed on one side of the page—you would create an XSLT fragment and insert a reference to it in the dynamic page. Creating XSLT fragments, and using them in conjunction with other dynamic pages to display XML data, is the more common scenario.
The first step in creating these types of pages is to create the XSLT fragment. It is a separate file that contains the layout, formatting, and so on of the XML data that you eventually want to display in the dynamic page. Once you create the XSLT fragment, you insert a reference to it in your dynamic page (for example, a PHP or ColdFusion page). The inserted reference to the fragment works much like an Server Side Include (SSI) — the formatted XML data (the fragment) resides in a separate file, while in Design view, a placeholder for the fragment appears on the dynamic page itself. When a browser requests the dynamic page containing the reference to the fragment, the server processes the included instruction and creates a new document in which the formatted contents of the fragment appear instead of the placeholder.
You use the XSL Transformation server behavior to insert the reference to an XSLT fragment in a dynamic page. When you insert the reference, Dreamweaver generates an includes/MM_XSLTransform/ folder in the site’s root folder that contains a runtime library file. The application server uses the functions defined in this file when transforming the specified XML data. The file is responsible for fetching the XML data and XSLT fragments, performing the XSL transformation, and outputting the results on the web page.
The file containing the XSLT fragment, the XML file containing your data, and the generated run-time library file must all be on the server for your page to display correctly. (If you select a remote XML file as your data source—one from an RSS feed, for example—that file must of course reside somewhere else on the Internet.)
You can also use Dreamweaver to create entire XSLT pages for use with server-side transformations. An entire XSLT page works in exactly the same way as an XSLT fragment, only when you insert the reference to the entire XSLT page using the XSL Transformation server behavior, you are inserting the full contents of an HTML page. Thus, the dynamic page (the .cfm, .php, or .asp page that acts as the container page) must be cleared of all HTML before you insert the reference.
Dreamweaver supports XSL transformations for ColdFusion, ASP, and PHP pages.
Your server must be correctly configured to perform server-side transformations. For more information, contact your server administrator.
You can perform XSL transformations on the client without the use of an application server. You can use Dreamweaver to create an entire XSLT page that will do this; however, client-side transformations require manipulation of the XML file that contains the data you want to display. Additionally, client-side transformations will only work in modern browsers (Internet Explorer 6, Netscape 8, Mozilla 1.8, and Firefox 1.0.2).
First, create an entire XSLT page and attach an XML data source. (Dreamweaver prompts you to attach the data source when you create the new page.) You can create an XSLT page from scratch, or you can convert an existing HTML page to an XSLT page. When you convert an existing HTML page to an XSLT page you must attach an XML data source using the Bindings panel (Window > Bindings).
After you’ve created your XSLT page, you must link it to the XML file containing the XML data by inserting a reference to the XSLT page in the XML file itself (much like you would insert a reference to an external CSS style sheet in the <head> section of an HTML page). Your site visitors must view the XML file (not the XSLT page) in a browser. When your site visitors view the page, the browser performs the XSL transformation and displays the XML data, formatted by the linked XSLT page.
The relationship between the linked XSLT and XML pages is conceptually similar, yet different from the external CSS/HTML page model. When you have an HTML page that contains content (such as text), you use an external style sheet to format that content. The HTML page determines the content, and the external CSS code, which the user never sees, determines the presentation. With XSLT and XML, the situation is reversed. The XML file (which the user never sees in its raw form), determines the content while the XSLT page determines the presentation. The XSLT page contains the tables, layout, graphics, and so forth that the standard HTML usually contains. When a user views the XML file in a browser, the XSLT page formats the content.
When you use Dreamweaver to link an XSLT page to an XML page, Dreamweaver inserts the appropriate code for you at the top of the XML page. If you own the XML page to which you’re linking (that is, if the XML file exclusively lives on your web server), all you need to do is use Dreamweaver to insert the appropriate code that links the two pages. When you own the XML file, the XSL transformations performed by the client are fully dynamic. That is, whenever you update the data in the XML file, any HTML output using the linked XSLT page will be automatically updated with the new information.
The XML and XSL files you use for client-side transformations must reside in the same directory. If they don’t, the browser will read the XML file and find the XSLT page for the transformation, but will fail to find assets (style sheets, images, and so on) defined by relative links in the XSLT page.
If you don’t own the XML page to which you’re linking (for example, if you want to use XML data from an RSS feed somewhere out on the web), the workflow is a bit more complicated. To perform client-side transformations using XML data from an external source, you must first download the XML source file to the same directory where your XSLT page resides. When the XML page is in your local site, you can use Dreamweaver to add the appropriate code that links it to the XSLT page, and post both pages (the downloaded XML file and the linked XSLT page) to your web server. When the user views the XML page in a browser, the XSLT page formats the content, just like in the previous example.
The disadvantage of performing client-side XSL transformations on XML data that comes from an external source is that the XML data is only partially “dynamic.” The XML file that you download and alter is merely a “snapshot” of the file that lives elsewhere on the web. If the original XML file out on the web changes, you must download the file again, link it to the XSLT page, and repost the XML file to your web server. The browser only renders the data that it receives from the XML file on your web server, not the data contained in the original XML source file.
The Repeating Region XSLT object lets you display repeating elements from an XML file within a page. Any region containing an XML data placeholder can be turned into a repeated region. However, the most common regions are a table, a table row, or a series of table rows.
The following example shows how the Repeating Region XSLT object is applied to a table row that displays menu information for a restaurant. The initial row displays three different elements from the XML schema: item, description, and price. When the Repeating Region XSLT object is applied to the table row, and the page is processed by an application server or a browser, the table is repeated with unique data inserted in each new table row.
When you apply a Repeating Region XSLT object to an element in the Document window, a thin, tabbed, gray outline appears around the repeated region. When you preview your work in a browser (File > Preview in Browser), the gray outline disappears and the selection expands to display the specified repeating elements in the XML file, as in the previous illustration.
When you add the Repeating Region XSLT object to the page, the length of the XML data placeholder in the Document window is truncated. This is because Dreamweaver updates the XPath (XML Path language) expression for the XML data placeholder so that it is relative to the path of the repeating element.
For example, the following code is for a table that contains two dynamic placeholders, without a Repeating Region XSLT object applied to the table:
<table width="500" border="1"> <tr> <td><xsl:value-of select="rss/channel/item/title"/></td> </tr> <tr> <td><xsl:value-of select="rss/channel/item/description"/></td> </tr> </table>
<xsl:for-each select="rss/channel/item"> <table width="500" border="1"> <tr> <td><xsl:value-of select="title"/></td> </tr> <tr> <td><xsl:value-of select="description"/></td> </tr> </table> </xsl:for-each>
In the previous example, Dreamweaver has updated the XPath for the items that fall within the Repeating Region (title & description) to be relative to the XPath in the enclosing <xsl:for-each> tags, rather than the full document.
Dreamweaver generates context-relative XPath expressions in other cases as well. For example, if you drag an XML data placeholder to a table that already has a Repeating Region XSLT object applied to it, Dreamweaver automatically displays the XPath relative to the existing XPath in the enclosing <xsl:for-each> tags.
When you use Preview in Browser (File > Preview in Browser) to preview XML data that you’ve inserted in an XSLT fragment or an entire XSLT page, the engine that performs the XSL transformation differs from situation to situation. For dynamic pages containing XSLT fragments, the application server always performs the transformation. At other times, either Dreamweaver or the browser might be performing the transformation.
The following table summarizes the situations when using Preview in Browser, and the engines that perform the respective transformations:
|Type of page previewed in browser||Data transformation performed by|
|Dynamic page containing XSLT fragment||Application server|
|XSLT fragment or entire XSLT page||Dreamweaver|
|XML file with link to entire XSLT page||Browser|
The following topics provide guidelines for helping you determine the appropriate previewing methods, based on your needs.
In the case of server-side transformations, the content the site visitor ultimately sees is transformed by your application server. When building XSLT and dynamic pages for use with server-side transformations, it is always preferable to preview the dynamic page that contains the XSLT fragment instead of the XSLT fragment itself. In the former scenario, you make use of the application server, which ensures that your preview is consistent with what your site visitors will see when they visit your page. In the latter scenario, Dreamweaver performs the transformation, and could provide slightly inconsistent results. You can use Dreamweaver to preview your XSLT fragment while you are building it, but you’ll be able to see the most accurate results of the data rendering if you use the application server to preview your dynamic page after you’ve inserted the XSLT fragment.
In the case of client-side transformations, the content the site visitor ultimately sees is transformed by a browser. You accomplish this by adding a link from the XML file to the XSLT page. If you open the XML file in Dreamweaver and preview it in a browser, you force the browser to load the XML file and perform the transformation. This provides you with the same experience as that of your site visitor.
Using this approach, however, makes it more difficult to debug your page because the browser transforms the XML and generates the HTML internally. If you select the browser’s View Source option to debug the generated HTML, you will only see the original XML that the browser received, not the full HTML (tags, styles, and so forth) responsible for the rendering of the page. To see the full HTML when viewing source code, you must preview the XSLT page in a browser instead.
When creating entire XSLT pages and XSLT fragments, you’ll want to preview your work to make sure that your data is being displayed correctly. If you use Preview in Browser to display an entire XSLT page or an XSLT fragment, Dreamweaver performs the transformation using a built‑in transformation engine. This method gives you quick results, and makes it easier for you to incrementally build and debug your page. It also provides a way for you to view the full HTML (tags, styles, and so forth) by selecting the View Source option in the browser.
This previewing method is commonly used when you begin building XSLT pages, regardless of whether you use the client or the server to transform your data.