The other way of selecting output is by passing one or more parameters from the PHP page to the XSLT fragment. This is much more interactive, because the decision about what to display is dynamically generated, unlike filters, which are hard-coded into the XSLT instructions.
Before using a parameter to change the content dynamically, you need to create a default parameter inside the XSLT fragment. Save books8.xslas books9.xsl, and continue work- ing with the new page.
1.Insert an XSLT parameter after the opening <xsl:output> tag (around line 15) like this:
<xsl:output method="html" encoding="utf-8"/>
<xsl:param name="pub" select="'friends of ED'"/>
<xsl:template match="/">
Creating a default parameter to select the publisher
18
The <xsl:param> tag takes two attributes: name, which is self-explanatory, and select, which sets the parameter value. Note that there are two sets of quotes around friends of ED. The double quotes surround the value of select, which is a string and must itself be enclosed in quotes. To avoid a clash, single quotes are used for the inner pair.
By declaring the parameter immediately after the <xsl:output>tag, you make it global in scope—in other words, available throughout the XSLT script.
2.Switch to Design view, select the xsl:for-eachtab that controls the repeat region for the entire table row, and click the lighting bolt icon in the Property inspector to open the XPath Expression Builder. You should see the same two filters as in step 6 of the last exercise.
3.Highlight the first filter (based on ListPrice), and click the minus button to remove it.
4.Click inside the Valuefield of the remaining filter to reveal a drop-down menu. You should now see your XSLT parameter listed with a dollar sign in front of it. Select
$pubin place of 'Apress', as shown in the following screenshot:
The Expressionfield should now read BookList/Book[Publisher = $pub]. Click OK. 5.Save books9.xsl, and view it in a browser. Only friends of ED books should be
listed.
Once you have defined a default parameter, you can use it to change the content of an XSLT fragment dynamically when it’s embedded in a PHP page.
This simple exercise demonstrates how you can toggle between displaying books pub- lished by Apress and friends of ED, using a jump menu to send the parameter to the XSLT fragment through a URL query string.
1.Create a new PHP page called books_param.php.
2.From the Insertmenu, select Form ➤Jump Menu.
3.In the Insert Jump Menu dialog box, insert Apress in the Text field, and insert
?pub=Apressin the field labeled When selected, go to URL. This will add the name and value of the parameter to a query string that will be added to the URL when the page reloads.
4.Click the plus button to add a second menu item. Insert friends of EDin the Text field and ?pub=friends of EDfor When selected, go to URL. Leave the other options in the dialog box unchanged. When you have finished, it should look like this:
Sending a parameter from a PHP page
5.Click OKto insert the jump menu, and then select the menu object in Design view.
In the Property inspector, change the name of the menu to pub. You also need the menu to display the currently selected value. Apart from the first time the page loads, this comes from the value of pubin the URL query string. Before clicking the Dynamicbutton in the Property inspector, you need to create a URL variable for Dreamweaver to use.
6.Open the Bindingspanel, click the plus button, and select URL variable. Type pubin the Namefield, and click OK.
7.Make sure the menu item is still selected in Design view, and click the Dynamicbut- ton in the Property inspector. When the Dynamic List/Menudialog box opens, click the lightning bolt icon alongside the field labeled Select value equal to.
8.Expand the URLtree in the Dynamic Datadialog box, select pub, and click OK. Also click OKin the Dynamic List/Menudialog box to close it.
9.Unfortunately, the code created by Dreamweaver needs tweaking slightly. Open Code view or Split view. The jump menu code should look like this:
18
10.Delete the two sections indicated in the preceding screenshot by removing ?pub=
from the PHP code. This is necessary because $_GET['pub']contains just the value of the pubvariable, not the whole query string. Be careful to remove the correct
sections—you still want the full query string in the value attribute of each
<option>tag.
11.$_GET['pub']won’t be set when the page first loads, so add the following code immediately above the opening <form>tag:
<?php if (!isset($_GET['pub'])) {$_GET['pub'] = 'Apress';} ?>
This sets the default value of pubto Apressand prevents any error from being gen- erated if the query string is missing. I’ve deliberately chosen the opposite default from the one in the XSLT fragment to show how passing a parameter from outside takes precedence over the value of selectin <xsl:param>.
12.Position your cursor just after the closing </form> tag, and switch back to Design view.
13.Embed the XSLT fragment by clicking the XSL Transformationbutton in the Datatab of the Insertbar. In the XSL Transformationdialog box, click the top Browsebutton, and select books9.xslas the XSLT file. Then click the plus button alongside XSLT parameters. Type pubin the Namefield of the Add Parameterdialog box, and click the lightning bolt icon to the right of the Valuefield. This opens the Dynamic Data dialog box, where you should select pubfrom the URLtree.
14.When you click OKto close the Dynamic Datadialog box, the Default valuefield is no longer grayed out in the Add Parameterdialog box. This is where you can insert a default value to be passed to the XSLT fragment. However, it’s not necessary because you created a default value in the <xsl:param> tag in the previous exercise.
15.When you click OKto close the Add Parameterdialog box, you’ll see the pubparam- eter listed, as shown in the following screenshot. An Editbutton has been added in case you need to make any changes. Click OKto close the XSL Transformationdia- log box.
16.Save books_param.php, and press F12/Opt+F12 to view it in a browser. It should look like Figure 18-9 (I have added a few minimal style rules to make it look a little more presentable). Even though the default parameter in the XSLT fragment was set to friends of ED, the parameter sent from the PHP page takes precedence.
17.Select friends of EDfrom the jump menu, and the display will change, showing only foED books.
Chapter review
This has been only a brief introduction to working with XSLT. It’s a massive and complex subject, but I think Dreamweaver has done a good job of making it more accessible to nonexperts. However, in spite of its power, XSLT has failed to take the web development community by storm. Although lack of browser support for client-side XSLT has played some part in holding it back, I think the main reason probably lies in the fact that XSLT on its own doesn’t style the output. It manipulates data in a similar way to PHP, and since most XML is generated dynamically from a database, developers prefer to go straight to the source and use more familiar server-side technologies. The nonintuitive syntax is also a major put off for many developers.
In the next chapter, we’ll look at handling XML with Spry, Adobe’s implementation of Ajax.
The Dreamweaver interface for handling Spry data sets has changed considerably since it was first introduced in Dreamweaver CS3. In addition to XML, Spry data sets can now be generated from an HTML source.
18
Figure 18-9.The contents of the XML document have been sorted, formatted, and displayed selectively through a combination of XSLT and PHP.
R E F R E S H C O N T E N T
The ability to manipulate data without the need to reload the web page lies at the very heart of Ajax. Done well, it can greatly improve the user experience: pages updated seam- lessly without the need to wait for all content to reload. However, the reality often leaves much to be desired. The biggest failing lies in pages that rely wholly on Ajax to load their content, leaving nothing for search engines to index. The implementation of Spry data sets in the previous version of Dreamweaver fell down badly on this score. If you disabled JavaScript in your browser and visited a photo gallery that drew its content from a Spry data set, you were greeted by a page of meaningless code. In Dreamweaver CS3, Spry was capa- ble of consuming data only from XML documents, so it was impractical to point visitors and search engines to alternative content without building two completely separate pages.
In response to criticism, Adobe has radically changed how you work with Spry data sets.
Spry can now extract data from tables and other HTML structures, in addition to XML. Of course, you still need to create the HTML page that the data set uses, but this can be done very quickly if the content is drawn from a database with a recordset and repeat region.
The advantages of using an HTML page as the data source are twofold: you’re using a familiar technology, so development should be faster; moreover, the HTML data source remains in the underlying code, thereby providing content for search engines to index, as well as for anyone visiting your site with JavaScript disabled. Building the Spry data set and a lot of its associated HTML is now handled by a sophisticated wizard.
So, what is a Spry data set? Basically, it’s the same as a recordset. However, instead of dis- playing all the results in the page when it loads, Spry retains most of the data in the browser’s memory. When you click a link or activate a menu, it uses DOM manipulation to replace the existing content with the relevant data stored in memory. It’s a useful tech- nique for displaying details of upcoming events, product information, or a photo gallery.
The data is loaded at the same time as the page is created, but you can set a timer mech- anism to update the data set periodically. However, sending asynchronous requests for new data is not supported through the Dreamweaver interface.
In this chapter, you’ll learn about the following:
Displaying images using details drawn from a database or a Spry data set Creating a Spry data set from HTML and XML data sources
Displaying data in a sortable table
Using a Spry detail region to display related information Distinguishing the different types of Spry repeat regions Building a Spry online photo gallery
You don’t need a deep knowledge of JavaScript to use Spry data sets. In fact, you don’t need any knowledge at all. Nevertheless, you’ll get more out of working with Spry if you know what the code looks like and what it’s for. So, this chapter also invites you to dive into Code view to see what’s going on under the hood.
For security reasons, browsers do not permit Spry and other Ajax frameworks to create data sets from a data source located on a different domain. To get around this restriction, use the XSLT server behavior, as described in the previous chapter, or access the data source through a proxy script (see the appendix for details of how to create a proxy script).