Dreamweaver Help and Guide

Resources

2009-02-07T17:53:00.000-08:00

Displaying Database Records

2009-01-28T09:32:00.001-08:00

Displaying database records involves retrieving information stored in a database or other source of content, and rendering that information to a web page. Macromedia Dreamweaver 8 provides many methods of displaying dynamic content, and provides several built-in server behaviors that let you both enhance the presentation of dynamic content, and allow users to more easily search through and navigate information returned from a database.

This chapter contains the following sections:

About displaying database records

Using predefined data formats

Creating recordset navigation links

Showing and hiding regions based on recordset results

Displaying multiple recordset results

Creating a table with a Repeat Region server behavior

Creating a record counter

About displaying database records

2009-01-28T09:31:00.002-08:00

Databases and other sources of dynamic content provide you with more power and flexibility in searching, sorting, and viewing large stores of information. Using a database to store content for web sites makes sense when you need to store large amounts of information, and then retrieve and display that information in a meaningful way. Dreamweaver provides you with several tools and prebuilt behaviors to help you effectively retrieve and display information stored in a database. The following sections describe the Dreamweaver server behaviors and formatting elements, and how you can use them to display dynamic content.

This section covers the following conceptual topics:

Server behaviors and formatting elements
Applying typographic and page layout elements to dynamic data
Navigating database recordset results
Custom recordset navigation bars
Displaying and hiding regions based on recordset results
Displaying multiple recordset results
Record counters

Server behaviors and formatting elements

2009-01-28T09:31:00.001-08:00

Dreamweaver provides the following server behaviors and formatting elements to let you enhance the display of dynamic data:

Formats let you apply different types of numerical, monetary, date/time, and percentage values to dynamic text.

For example, if the price of an item in a recordset reads 10.989, you can display the price on the page as $10.99 by selecting the Dreamweaver "Currency - 2 Decimal Places" format. This format displays a number using two decimal places. If the number has more than two decimal places, the data format rounds the number to the closest decimal. If the number has no decimal places, the data format adds a decimal point and two zeros.

Repeated Region server behaviors let you display multiple items returned from a database query, and let you specify the number of records to display per page.

Recordset Navigation server behaviors let you insert navigation elements that allow users to move to the next or previous set of records returned by the recordset. For example, if you choose to display 10 records per page using the Repeated Region server object, and the recordset returns 40 records, you can navigate through the records 10 at a time.

Recordset Status Bar server behaviors let you include a counter that shows users where they are within a set of records relative to the total number of records returned.

Show Region server behaviors let you choose to show or hide items on the page based on the relevance of the currently displayed records. For example, if a user has navigated to the last record in a recordset, you can hide the "next" link, and display only the "previous" records link.

Applying typographic and page layout elements to dynamic data

2009-01-28T09:30:00.002-08:00

A powerful feature of Dreamweaver is the ability to present dynamic data within a structured page, and to apply typographic formatting using HTML and CSS. To apply formats to dynamic data in Dreamweaver, format the tables and placeholders for the dynamic data using the Dreamweaver formatting tools. When the data is inserted from its data source, it will automatically adopt the font, paragraph, and table formatting you specified.

To learn about Dreamweaver formatting features, and how to apply them to dynamic data elements, see Presenting Content with Tables and Inserting and Formatting Text.

Navigating database recordset results

2009-01-28T09:30:00.001-08:00

Recordset navigation links let users move from one record to the next, or from one set of records to the next. For example, after designing a page to display five records at a time, you might want to add links such as "Next" or "Previous" that let users display the five next or previous records.

Dreamweaver lets you create four types of navigation links to move through a recordset: First, Previous, Next, and Last. A single page can contain any number of these links, provided they all work on a single recordset. You can’t add links to move through a second recordset on the same page.

NOTE

Microsoft ASP.NET refers to a recordset as a DataSet. If you are working with ASP.NET document types, the dialog boxes and menu choices specific to ASP.NET use the label DataSet. The Dreamweaver documentation generically refers to both types as recordsets, but uses DataSet when specifically describing ASP.NET features.

Recordset navigation links require the following dynamic elements:

A recordset to navigate
Dynamic content on the page to display the record or records
Text or images on the page to serve as a clickable navigation bar
A "Move To Record" set of server behaviors to navigate the recordset

You can add the last two elements using the Record Navigation Bar server object, or you can add them separately using the Dreamweaver design tools and the Server Behaviors panel.

Custom recordset navigation bars

2009-01-28T09:29:00.000-08:00

If you want to create a recordset navigation bar that uses more complex layout and formatting styles than the simple table created by the Recordset Navigation Bar server object, you might prefer to create your own navigation bar. To do this, you must first create the necessary navigation links in either text or images, place them within the page in Design view, and assign individual server behaviors to each navigation link.

You can assign the following individual server behaviors to navigation links:

Move to first page
Move to last page
Move to next page
Move to previous page

If you would prefer to use the Dreamweaver built-in Recordset Navigation Bar server object to create a navigation bar, see Creating a navigation bar using the Recordset Navigation Bar server behavior.

Navigation bar design tasks

2009-01-28T09:28:00.002-08:00

When creating a custom navigation bar, begin by creating its visual representation using the Dreamweaver page-design tools. You don’t have to create a link for the text string or image, Dreamweaver will create one for you.

The page you create the navigation bar for must contain a recordset to navigate. For more information, see Understanding recordsets.

A simple recordset navigation bar might look like this, with link buttons created out of images, or other content elements:

After you have added a recordset to a page, and have created a navigation bar, you must apply individual server behaviors to each navigation element. For example, a typical recordset navigation bar contains representations of the following links matched to the appropriate behavior:

Navigation link

Server behavior

Go to first page

Move to first page

Go to previous page

Move to previous page

Go to next page

Move to next page

Go to last page

Move to last page

Displaying and hiding regions based on recordset results

2009-01-28T09:28:00.001-08:00

Dreamweaver includes a set of server behaviors that let you show or hide a region based on the results returned by a recordset. For example, in a page using "Previous" and "Next" record links to navigate a results page, you can specify that the "Previous" records link be shown on all results pages except the first (which has no previous results), and that the "Next" records link be shown on all pages except the last (which has no next results).

You can also specify that a region be displayed or hidden based on whether the recordset is empty or not. If a recordset is empty (for example, no records were found matching the query), you can display a message informing the user that no records were returned. This is especially useful when creating search pages that rely on user input search terms to run queries against. Similarly, you can display an error message if there is a problem connecting to a database, or if a user’s user name and password do not match those recognized by the server.

The Show Region server behaviors are:

Show If Recordset Is Empty
Show If Recordset Is Not Empty
Show If First Page
Show If Not First Page
Show If Last Page
Show If Not Last Page

To learn how to apply the Show Region server behaviors, see Showing and hiding regions based on recordset results.

Displaying multiple recordset results

2009-01-28T09:27:00.002-08:00

The Repeat Region server behavior lets you display multiple records from a recordset within a page. Any dynamic data selection 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 illustrates how the Repeat Region server behavior is applied to a table row, and specifies that nine records are displayed per page. The row itself displays four different records: city, state, street address, and zip code.

To create a table such as the one shown above, you must create a table containing dynamic content, and apply the Repeat Region server behavior to the table row containing the dynamic content. When the page is processed by the application server, the row is repeated the number of times specified in the Repeat Region server object, with a different record inserted in each new row.

To learn how to apply the Repeat Region server behavior, see Displaying multiple recordset results and Creating a table with a Repeat Region server behavior.

Record counters

2009-01-28T09:27:00.001-08:00

Record counters give users a reference point when they are navigating through a set of records. Typically, record counters display the total number of records returned, and the current records being viewed. For example, if a recordset returns 40 individual records, and 8 records are displayed per page, the record counter on the first page would indicate "Displaying records 1-8 of 40."

To create a record counter for a page, you must first create a recordset for the page, an appropriate page layout to contain the dynamic content, and a recordset navigation bar. To learn more about creating these elements, and adding them to a page, see the following sections:

Understanding recordsets
Creating recordset navigation links
Displaying multiple recordset results
Creating a table with a Repeat Region server behavior

Once you have the above elements in the page, you can create a record counter.

Simple record counters

You can create a simple record counter using the Recordset Navigation Status server object. This server object inserts a complete record counter that you can apply text formatting to using Dreamweaver page-design tools. To learn more about this record counter, see Creating a record counter using the Recordset Navigation Status object.

Custom record counters

You can use individual record count behaviors to create custom record counters. Creating a custom record counter allows you to create a record counter beyond the simple, single row table inserted by the Recordset Navigation Status server object. You can arrange design elements in a number of creative ways, and apply an appropriate server behavior to each element.

The Record Count server behaviors are:

Display Starting Record Number
Display Ending Record Number
Display Total Records

Creating custom record counters leads you through the steps to create a record counter by applying the individual Record Counter server behaviors to a page’s design elements.

Using predefined data formats

2009-01-28T09:23:00.000-08:00

Dreamweaver comes with several predefined data formats that you can apply to dynamic data elements. The data format styles include date and time, currency, numerical, and percentage formats.

To apply data formats to dynamic content:

Select the dynamic content in either the Live Data window or its placeholder in the Document window.
Select Window > Bindings to display the Bindings panel.
Click the down arrow button in the Format column.
If the down arrow is not visible, expand the panel.
From the Format pop-up menu, select the data format category you want.
Ensure that the data format is appropriate for the type of data you are formatting. For example, the Currency formats work only if the dynamic data consists of numerical data. Note that you cannot apply more than one format to the same data.
Verify that the format was applied correctly by previewing the page in either the Live Data window or a browser.

Customizing existing data formats

2009-01-28T09:22:00.000-08:00

You can customize the Dreamweaver existing data formats or create your own.

To customize a data format:

Open a page that contains dynamic data in Design view.
Select the dynamic data whose format you want to customize.
Select Window > Bindings to display the Bindings panel.
The bound data item whose dynamic text you selected will be highlighted.
Click the down arrow in the Format column to expand the pop-up menu of available data formats.
If the down arrow is not visible, expand the panel.
Select Edit Format List from the pop-up menu.
The Edit Format List dialog box appears.
Complete the dialog box and click OK.
For instructions, see Setting the Edit Format List dialog box options.

Creating new data formats

2009-01-28T09:21:00.000-08:00

You can create new data formats to suit any type of dynamic data you want to display.

To create a new data format:

Open a page containing dynamic data in Design view.
Select the dynamic data you want to create a custom format for.
Select Window > Bindings to display the Bindings panel, and click the down arrow in the Format column.
If the down arrow is not visible, expand the panel.
Select Edit Format List from the pop-up menu.
The Edit Format List dialog box appears.
Click the Plus (+) button and select a format type.
Define the format and click OK.
Enter a name for the new format in the Name column.
Click OK to close the Edit Format List dialog box.

Creating recordset navigation links

2009-01-28T09:20:00.000-08:00

Recordset navigation links let users move from one record to the next, or from one set of records to the next. For example, after designing a page to display five records at a time, you might want to add links such as Next or Previous that let users display the five next or previous records.

You can create recordset navigation links either by using the Recordset Navigation Bar server behavior or you can create a custom recordset navigation bar.

This section covers the following topics:

Creating a navigation bar using the Recordset Navigation Bar server behavior
Creating a custom recordset navigation bar

Creating a navigation bar using the Recordset Navigation Bar server behavior

2009-01-28T09:06:00.004-08:00

You can create a recordset navigation bar in a single operation using the Recordset Navigation Bar server behavior. The server object adds the following building blocks to the page:

An HTML table with either text or image links
A set of "Move to" server behaviors
A set of "Show Region" server behaviors

The text version of the Recordset Navigation Bar looks like this:

The image version of the Recordset Navigation Bar looks like this:

Before placing the navigation bar on the page, make sure the page contains a recordset to navigate and a page layout in which to display the records.

After placing the navigation bar on the page, you can use the Dreamweaver design tools to customize the bar to your liking. You can also edit the "Move to" and "Show Region" server behaviors by double-clicking them in the Server Behaviors panel.

If you want to build the navigation bar block by block using the Dreamweaver design tools and the Server Behaviors panel, see Creating a custom recordset navigation bar.

To create the recordset navigation bar with the server object:

In Design view, place the insertion point at the location on the page where you want the navigation bar to appear.
Display the Recordset Navigation Bar dialog box (Insert > Application Objects > Recordset Navigation Bar).
The Insert Recordset Navigation Bar dialog box appears.
Select the recordset you want to navigate from the Recordset pop-up menu.
From the Display Using section, select the format to display the navigation links on the page. The Text option places text links on the page, while the Images option lets you use graphical images as links.
In the image version of the navigation bar, Dreamweaver uses its own image files. You can replace these images with image files of your own after placing the bar on the page.
Click OK.
Dreamweaver creates a table that contains text or image links that allow the user to navigate through the selected recordset when clicked. When the first record in the recordset is displayed, the First and Previous links or images are hidden. When the last record in the recordset is displayed, the Next and Last links or images are hidden.

You can customize the layout of the navigation bar using the Dreamweaver design tools.

Creating a custom recordset navigation bar

2009-01-28T09:06:00.003-08:00

You can create a custom recordset navigation bar that uses more complex layout and formatting styles than that offered by the simple table used by the Recordset Navigation Bar server object.

To create your own recordset navigation bar, you must:

Design navigation links using either text or images
Place the links in the page in Design view
Assign individual server behaviors to each navigation link

To learn more about designing a custom recordset navigation bar, see Custom recordset navigation bars. If you prefer to use the Dreamweaver built-in Recordset Navigation Bar server object to create a navigation bar, see Creating a navigation bar using the Recordset Navigation Bar server behavior.

This procedure describes how to assign individual server behaviors to the navigation links.

To assign server behaviors to recordset navigation links:

In Design view, select the text string or image on the page you want to use as a record navigation link.
Open the Server Behaviors panel (Window > Server Behaviors) and click the Plus (+) button.
Select Recordset Paging from the pop-up menu; then select a server behavior appropriate to that link from the listed server behaviors.
If the recordset contains a large number of records, the Move to Last Record server behavior can take a long time to run when the user clicks the link.
In the Recordset pop-up menu, select the recordset containing the records.
Click OK.
The server behavior is assigned to the navigation link.

Showing and hiding regions based on recordset results

2009-01-28T09:06:00.001-08:00

Dreamweaver includes a set of server behaviors that let you show or hide a region based on the results returned by a recordset. To learn more about the Show Region server behaviors, and how they can be used to show or hide recordset results, see Displaying and hiding regions based on recordset results.

To show a region only when it’s needed:

In Design view, select the region on the page to show or hide.
In the Server Behaviors panel (Window > Server Behaviors), click the Plus (+) button.
Select Show Region from the pop-up menu, and then select one of the listed server behaviors.
Click OK.

Displaying multiple recordset results

2009-01-28T09:05:00.001-08:00

To learn more about using the Repeat Region server behavior, see Displaying multiple recordset results and Creating a table with a Repeat Region server behavior.

To create a repeated region:

In Design view, select a region that contains dynamic content.
The selection can be anything, including a table, a table row, or even a paragraph of text.

To select a region on the page precisely, you can use the tag selector on the left corner of the document window. For example, if the region is a table row, click inside the row on the page, then click the rightmost tag in the tag selector to select the table row.
Select Window > Server Behaviors to display the Server Behaviors panel.
Click the Plus (+) button, and select Repeat Region.
The Repeat Region dialog box appears.
Select the name of the recordset to use from the pop-up menu.
Select the number of records to display per page.
Click OK.
In the Document window, a thin, tabbed, gray outline appears around the repeated region. In the Live Data window (View > Live Data), the gray outline disappears and the selection expands to display the number of records you specified.

Creating a table with a Repeat Region server behavior

2009-01-28T09:04:00.002-08:00

The Dynamic Table server object lets you create a table containing dynamic content and apply the Repeat Region behavior from a single dialog box. This server object is especially useful as it simultaneously populates a table with dynamic content from a recordset and applies the Repeat Region server behavior.

NOTE

The Dynamic Table server object is not available when using ASP.NET document types. To create a table containing dynamic content and repeating regions, you must manually insert the table, insert dynamic content from the Bindings panel, and apply a Repeat Region server behavior if needed. For more information, see Displaying multiple recordset results.

To create a dynamic table:

To insert a dynamic table:
- Select Insert > Application Objects > Dynamic Data > Dynamic Table to display the Dynamic Table dialog box.
- From the Application category of the Insert bar, select the Dynamic Table button in the Dynamic Data menu.
The Dynamic Table dialog box appears.
Select the recordset you want to use from the Recordset pop-up menu.
Select the number of records to display per page.
Input values for the table border, cell padding, and cell spacing if desired.
The Dynamic Table dialog box retains the values you enter for table borders, cell padding, and cell spacing. If you are working on a project that will need several dynamic tables requiring the same look, you may want to enter the table layout values, as this will further simplify page development. Note that you can adjust these values after inserting the table using the table Property inspector.
Click OK.
A table and placeholders for the dynamic content defined in its associated recordset are inserted into the page.
In this example, the recordset contains four records: FIRSTNAME, LASTNAME, TITLE, and DEPARTMENT. The table’s Heading row is populated with the names of each record item. You can edit the headings using any descriptive text you want, or replace them with representative images.

Creating a record counter

2009-01-28T09:04:00.001-08:00

Record counters let users know where they are within a given set of records relative to the total number of records returned. For this reason record counters are a useful behavior that can significantly add to the usability of a web page.

To learn more about record counters, see Record counters.

This section covers the following topics:

Creating a record counter using the Recordset Navigation Status object

Creating custom record counters

Creating a record counter using the Recordset Navigation Status object

2009-01-28T09:03:00.002-08:00

The Recordset Navigation Status object creates a text entry on the page to display the current record status.

To use the Recordset Navigation Status server object:

Place the insertion point where you want to insert the record counter.
Select Insert > Application Objects > Recordset Navigation Status.
The Insert Recordset Navigation Status dialog box is displayed.
Select the recordset you want to use from the Recordset pop-up menu.
Click OK.
The Recordset Navigation Status server object inserts a text record counter that appears similar to the one shown below:

You can use the Dreamweaver page-design tools to customize the record counter.

When viewed in the Live Data window or a browser, the counter will appear similar to the one shown below:

Creating custom record counters

2009-01-28T09:03:00.001-08:00

To create a custom record counter for a page, you must first create a recordset for the page, an appropriate page layout to contain the dynamic content, and a recordset navigation bar. To learn more about creating these elements and adding them to a page, see Record counters. After you have created the above elements in the page, you can create a custom record counter.

This example creates a record counter that will appear similar to that created in the previous section, Creating a record counter using the Recordset Navigation Status object. The record counter in this example will appear as follows:

Displaying records StartRow thru EndRow of RecordSet.RecordCount.

In this example, the text in sans-serif font represents the record count placeholders that will be inserted in the page.

To create a custom record counter:

In Design view, enter the counter’s text on the page. The text can be anything you want. For example:
```
Displaying records thru of . 
```
Place the insertion point at the end of the text string.
Open the Server Behaviors panel (Window > Server Behaviors).
Click the Plus (+) button in the upper-left corner, and click Display Record Count. Within this submenu, select Display Total Records. The Display Total Records behavior is inserted into the page, and a placeholder is inserted where the insertion point was. The text string should now appear as:
```
Displaying records thru of {Recordset1.RecordCount}. 
```
Place the insertion point after the word records, and select the Display Starting Record Count Number from the Server Behaviors > Plus (+) button > Record Count panel. The text string should now appear as:
```
Displaying records {StartRow_Recordset1} thru of {Recordset1.RecordCount}. 
```
Now place the insertion point between the words thru and of, and select the Display Starting Record Count Number from the Server Behaviors > Plus (+) button > Record Count panel. The text string should now appear as:
```
Displaying records {StartRow_Recordset1} thru {EndRow_Recordset1} of {Recordset1.RecordCount}. 
```
Confirm that the counter functions correctly by viewing the page in the Live Data window (View > Live Data); the counter should now look similar to the following example:
```
Displaying records 1 thru 8 of 40. 
```
If the results page has a navigation link to move to the next set of records, clicking the link would update the record counter to read as follows:
```
Showing records 9 thru 16 of 40. 
```
Links don’t work in the Live Data window. To test them, you can use the Preview in Browser feature in Dreamweaver. Make sure the Preview Using Live Data Server option is selected in Preferences (Edit > Preferences > Preview in Browser (Windows) or Dreamweaver > Preferences > Preview in Browser (Macintosh)); then select File > Preview in Browser.

Displaying XML Data in Web Pages

2009-01-28T09:02:00.001-08:00

You can use Macromedia Dreamweaver 8 to create web pages that display XML data. Displaying XML data involves retrieving information stored in a local or remote XML file and rendering that information in a web page. Dreamweaver provides methods for displaying information from XML files, as well as built-in XSLT objects and design features that let you enhance the presentation of your XML data.

This chapter contains the following sections:

About using XML and XSL with web pages

About server-side XSL transformations

About client-side XSL transformations

About XML data and repeating elements

About previewing XML data

Performing XSL transformations on the server

Performing XSL transformations on the client

Applying styles to XSLT fragments

Troubleshooting XSL transformations

About using XML and XSL with web pages

2009-01-28T09:01:00.000-08:00

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. 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 illustrates the basic structure of an XML file:

            03/01/2004              Charles Brown               04/08/2004              John Thompson

In this example, each parent tag contains three child tags: , , and . But each tag is also a child tag of the tag, which is one level higher in the schema. You can name and structure XML tags in any way you like, 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. When you perform a server-side XSL transformation, the server does the work of transforming the XML and XSL, and displaying it on the page. When you perform 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. Lastly, 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 more information, see About server-side XSL transformations, and About client-side XSL transformations.

About server-side XSL transformations

2009-01-28T09:00:00.004-08:00

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 tag and a 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 or 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 Macromedia 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, .asp, or .net 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, ASP.NET, and PHP pages.

NOTE

Your server must be correctly configured to perform server-side transformations. For more information, contact your server administrator, or visit www.macromedia.com/go/dw_xsl.

For procedures on creating server-side XSL transformations, see Performing XSL transformations on the server.

About client-side XSL transformations

2009-01-28T09:00:00.003-08:00

You can also 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). For more information on browsers that do and don’t support XSL transformations, see www.w3schools.com/xsl/xsl_browsers.asp.

You begin by creating an entire XSLT page and attaching an XML data source. (Dreamweaver prompts you to attach the data source when you create the new page.) You can use Dreamweaver to 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).

Once 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 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.

NOTE

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. Once 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 to 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.

For procedures on creating client-side XSL transformations, see Performing XSL transformations on the client.

About XML data and repeating elements

2009-01-28T09:00:00.001-08:00

The Repeat 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 illustrates how the Repeat 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 Repeat 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 Repeat Region XSLT object 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.

You might also notice that when you add the Repeat Region XSLT object to the page, Dreamweaver truncates the length of the XML data placeholder in the Document window. This is because Dreamweaver updates the XPath 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 Repeat Region XSLT object applied to the table:

The following code is for the same table with the Repeat Region XSLT object applied to it:

In the previous example, Dreamweaver has automatically updated the XPath for the items that fall within the Repeat Region (title & description) to be relative to the XPath in the enclosing 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 Repeat Region XSLT object applied to it, Dreamweaver automatically displays the XPath relative to the existing XPath in the enclosing tags.

To learn how to apply the Repeat Region XSLT object, see Displaying repeating XML elements.

About previewing XML data

2009-01-28T08:59:00.005-08:00

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:

Previewing pages for server-side transformations
Previewing pages for client-side transformations
Previewing entire XSLT pages and XSLT fragments

Previewing pages for server-side transformations

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.

Previewing pages for client-side transformations

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.

One disadvantage of this approach is that it makes it harder for you 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.

Previewing entire XSLT pages and XSLT fragments

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.

NOTE

You will most likely use this method when you begin building XSLT pages, regardless of whether you use the client or the server to transform your data.

Performing XSL transformations on the server

2009-01-28T08:59:00.003-08:00

Performing XSL transformations on the server

You can use Dreamweaver to create entire XSLT pages or XSLT fragments for use in dynamic web pages. An entire XSLT page is a page that, when transformed, generates a full HTML page. An XSLT fragment is a piece of code, used by a separate document, that, when transformed, displays XML data.

Macromedia recommends that you read About server-side XSL transformations before proceeding with any of the following procedures.

NOTE

Your server must be correctly configured to perform server-side transformations. For more information, contact your server administrator, or visit www.macromedia.com/go/dw_xsl.

This section contains the following topics:

Workflow for performing server-side XSL transformations
Creating XSLT pages
Converting HTML pages to XSLT pages
Attaching XML data sources
Displaying XML data in XSLT pages
Displaying repeating XML elements
Editing a Repeat Region XSLT object
Inserting XSLT fragments in dynamic pages
Deleting XSLT fragments from dynamic pages
Editing XSL Transformation server behaviors
Using parameters with XSL transformations
Creating conditional XSLT regions
Editing a Conditional Region XSLT object
Inserting XSL comments

Workflow for performing server-side XSL transformations

2009-01-28T08:59:00.001-08:00

This section provides a list of steps you need to follow to perform server-side XSL transformations, and refers you to the sections in the documentation that elaborate on each procedure.

Macromedia recommends that you read About using XML and XSL with web pages, About server-side XSL transformations, and About client-side XSL transformations before building pages that display XML data.

To perform server-side XSL transformations, follow these steps:

Set up a Dreamweaver site. See Setting Up a Dreamweaver Site.
Choose a server technology and set up an application server. See Setting up an application server.
Test the application server to make sure it is functioning correctly. For example, create a page that requires processing, and make sure that the application server processes the page. For a tutorial on how to do this, visit www.macromedia.com/go/dw_xsl.
Do one of the following:
- In your Dreamweaver site, create an XSLT fragment or an entire XSLT page. See Creating XSLT pages.
- Convert an existing HTML page to an entire XSLT page. See Converting HTML pages to XSLT pages.
If you haven’t already done so, attach an XML data source to the page. See Attaching XML data sources.
Bind your XML data to the XSLT fragment or to the entire XSLT page. See Displaying XML data in XSLT pages.
If appropriate, add a Repeat Region XSLT object to the table or table row that contains the XML data placeholder(s). See Displaying repeating XML elements.
Do one of the following:
- Use the XSL Transformation server behavior to insert a reference to the XSLT fragment in your dynamic page. See Inserting XSLT fragments in dynamic pages.
- Delete all of the HTML code from a dynamic page, and then use the XSL Transformation server behavior to insert a reference to the entire XSLT page in the dynamic page.
Post both the dynamic page and the XSLT fragment (or entire XSLT page) to your application server. If you are using a local XML file, you will need to post that as well.
View the dynamic page in a browser. When you do so, the application server transforms the XML data, inserts it in the dynamic page, and displays it in the browser.

Creating XSLT pages

2009-01-28T08:58:00.003-08:00

You can create XSLT pages that let you display XML data on web pages. You can create either an entire XSLT page -- an XSLT page that contains a tag and a tag -- or you can create an XSLT fragment. When you create an XSLT fragment, you create an independent file that contains no body or head tag -- a simple piece of code that is later inserted in a dynamic page.

NOTE

If you are starting with an existing XSLT page, and need to attach an XML data source to it, see Attaching XML data sources.

To create an XSLT page:

Select File > New
On the General tab of the New Document dialog box, select Basic page from the Category column and do one of the following:
- Select XSLT (Entire page) from the Basics page column to create an entire XSLT page.
- Select XSLT (Fragment) from the Basics page column to create an XSLT fragment.
Click Create.
The Locate XML Source dialog box appears, asking you to attach an XML data source.
Do one of the following:
- Select Attach a local file, click the Browse button, browse to a local XML file on your computer, and click OK.
- Select Attach a remote file, enter the URL of an XML file on the Internet (such as one coming from an RSS feed), and click OK.
  
  NOTE
  
  Clicking the Cancel button will generate a new XSLT page with no attached XML data source. For information on attaching XML data sources, see Attaching XML data sources.
Dreamweaver populates the Bindings panel with the schema of your XML data source.

The following table provides an explanation of the various elements in the schema that might appear:

Element	Represents	Details
<>	Required nonrepeating XML element	An element that appears exactly once within its parent node
<>+	Repeating XML element	An element that appears one or more times within its parent node
<>?	Optional XML element	An element that appears zero or more times within its parent node
Element node in boldface type	Current context element	Normally the repeating element when the insertion point is inside a repeat region
@	XML attribute

Save your new page (File > Save) with the .xsl or .xslt extension (.xsl is the default).

Converting HTML pages to XSLT pages

2009-01-28T08:58:00.001-08:00

You can also convert existing HTML pages to XSLT pages. For example, if you have a predesigned static page to which you want to add XML data, you can convert the page to an XSLT page, instead of creating an XSLT page and redesigning the page from scratch.

To convert an existing HTML page to an XSLT page:

Open the HTML page that you want to convert.
Select File > Convert > XSLT 1.0.
Dreamweaver opens a copy of the page in the Document window. The new page is an XSL style sheet, saved with the .xsl extension.

Attaching XML data sources

2009-01-28T08:57:00.002-08:00

If you are starting with an existing XSLT page, or if you don’t attach an XML data source when creating a new XSLT page with Dreamweaver, you will need to attach an XML data source using the Bindings panel.

To attach an XML data source:

In the Bindings panel (Window > Bindings), click the XML link.

NOTE

You can also click the Source link at the upper-right corner of the Bindings panel to add an XML data source.
Do one of the following:
- Select Attach a Local File, click the Browse button, browse to a local XML file on your computer, and click OK.
- Select Attach a Remote File, enter the URL of an XML file on the Internet (such as one coming from an RSS feed).
Click OK to close the Locate XML Source dialog box.
Dreamweaver populates the Bindings panel with the schema of your XML data source. For a guide to the symbols in the schema, see Creating XSLT pages.

Displaying XML data in XSLT pages

2009-01-28T08:57:00.001-08:00

Once you’ve created an XSLT page and attached an XML data source, you can bind data to the page.

To display XML data:

Open an XSLT page with an attached XML data source. For instructions, see Creating XSLT pages.

(Optional) Select Insert > Table to add a table to the page. A table helps you organize your XML data. For more information, see Presenting Content with Tables.

NOTE

In most cases, you will want to use the Repeat Region XSLT object to display repeating XML elements on a page. If this is the case, you might want to create a single-row table with one or more columns, or a two-rowed table if you want to include a table header. For more information, see Displaying repeating XML elements.

In the Bindings panel, select an XML element and drag it to the place on the page where you want to insert data.
An XML data placeholder appears on the page. The placeholder is highlighted and in curly brackets. It uses the XPath (XML Path language) syntax to describe the hierarchical structure of the XML schema. For example, if you drag the child element "title" to the page, and that element has the parent elements "rss," "channel," and "item," then the syntax for the dynamic content placeholder will be {rss/channel/item/title}.

Once an XML data placeholder is on the page, you can double-click it to open the XPath Expression Builder. The XPath Expression builder lets you format selected data, or select other items from the XML schema. For more information, click the Help button in the XPath Expression builder.
(Optional) Apply styles to your XML data by selecting an XML data placeholder and applying styles to it like any other piece of content using the Property inspector or the CSS Styles panel. Alternatively, you can use Design-time style sheets to apply styles to XSLT fragments. Each of these methods has its own set of benefits and limitations. For more information, see Applying styles to XSLT fragments.

Preview your work in a browser (File > Preview in Browser)

NOTE

When you preview your work using Preview in Browser, Dreamweaver performs an internal XSL transformation without the use of an application server. For more information, see About previewing XML data.

Displaying repeating XML elements

2009-01-28T08:56:00.004-08:00

The Repeat Region XSLT object lets you display repeating elements from an XML data source in a web page. For example, if you are displaying article titles and descriptions from a news feed, and that news feed contains between 10 and 20 articles, each title and description in the XML file would probably be a child element of a repeating element.

Any region in Design view containing an XML data placeholder can be turned into a repeated region. However, the most common regions are tables, table rows, or a series of table rows.

To learn more about how the Repeat Region XSLT object works with XML data, see About XML data and repeating elements.

To display repeating XML elements:

In Design view, select a region that contains an XML data placeholder or placeholders.
The selection can be anything, including a table, a table row, or even a paragraph of text.

TIP

To select a region on the page precisely, you can use the tag selector in the lower-left corner of the Document window. For example, if the region is a table, click inside the table on the page, and then click the tag in the tag selector.


 Do one of the following   Select Insert > XSLT Objects > Repeat Region.  
In the XSLT category of the Insert bar, click the Repeat Region button.  
 
In the XPath Expression Builder, select the repeating element, indicated by  a small plus sign.

For more information, click the Help button in the dialog box.
 Click OK.  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.
 You’ll also notice that when you add the Repeat Region XSLT object to the  page, Dreamweaver truncates the length of the XML data placeholder in the  Document window. This is because Dreamweaver updates the XPath for the XML data  placeholder so that it is relative to the path of the repeating element.
 For more information, see About XML data and  repeating elements.

Editing a Repeat Region XSLT object

2009-01-28T08:56:00.003-08:00

After you’ve added a Repeat Region XSLT object to a region, you can make changes to it using the Property inspector.

To edit a Repeat Region XSLT object:

Select the object by clicking the gray tab that surrounds the repeated region.
In the Property inspector (Window > Properties), click the dynamic icon next to the Select text field.
In the XPath Expression Builder, make your changes and click OK.

Inserting XSLT fragments in dynamic pages

2009-01-28T08:56:00.001-08:00

Once you have created an XSLT fragment, you can insert it in a dynamic web page using the XSL Transformation server behavior. When you add the server behavior to your page and view the page in a browser, an application server performs a transformation that displays the XML data from the selected XSLT fragment. Dreamweaver supports XSL transformations for ColdFusion, ASP, ASP.NET, or PHP pages.

NOTE

If you want to insert the contents of an entire XSLT page in a dynamic page, the procedure is exactly the same. Before using the XSL Transformation server behavior to insert the entire XSLT page, delete all HTML code from the dynamic page. For more information, see About server-side XSL transformations.

To insert an XSLT fragment in a web page:

Open an existing ColdFusion, ASP, ASP.NET, or PHP page.

In Design view, place the insertion point in the location where you want to insert the XSLT fragment.

NOTE

When inserting XSLT fragments, you should always click the Show Code and Design view button after placing the insertion point on the page so that you can ensure that the insertion point is in the correct location. If it isn’t, you might need to click somewhere else in Code view to place the insertion point where you want it.

In the Server Behaviors panel (Window > Server Behaviors), click the Plus (+) button and select XSL Transformation.
In the XSL Transformation dialog box, click the Browse button and browse to an XSLT fragment or an entire XSLT page. For more information, see Creating XSLT pages.
Dreamweaver automatically populates the next text field with the file path or URL of the XML file that is attached to the specified fragment. To change it, click the Browse button and browse to another file.
(Optional) Click the Plus (+) button to add an XSLT parameter. For more information, see Using parameters with XSL transformations.
Click OK.
Dreamweaver inserts a reference to the XSLT fragment in the page. The fragment is not editable. You can double-click the fragment to open the fragment’s source file and edit it.

Dreamweaver also creates 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 to perform the transformation. For more information, see About server-side XSL transformations.
Upload the dynamic page to your server (Site > Put). When Dreamweaver gives you the option of including dependent files, click Yes. 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 selected a remote XML file as your data source, that file must of course reside somewhere else on the Internet.)

Deleting XSLT fragments from dynamic pages

2009-01-28T08:55:00.002-08:00

You can remove an XSLT fragment from a page by deleting the XSL Transformation server behavior used to insert the fragment. Deleting the server behavior deletes the XSLT fragment only -- it does not delete the associated XML, XSLT, or run-time library files.

To delete an XSLT fragment from a dynamic page:

In the Server Behaviors panel (Window > Server Behaviors), select the XSL Transformation server behavior that you want to delete.

Click the minus (-) button.

NOTE

Macromedia recommends that you always remove server behaviors in this fashion. Manually deleting the generated code only partially removes the server behavior, even though the server behavior may disappear from the Server Behaviors panel.

Editing XSL Transformation server behaviors

2009-01-28T08:55:00.001-08:00

Once you’ve added an XSLT fragment to a dynamic web page, you can edit the XSL Transformation server behavior at any time.

To edit an XSL Transformation server behavior:

In the Server Behaviors panel (Window > Server Behaviors), double-click the XSL Transformation server behavior that you want to edit.
Make your changes and click OK.

Using parameters with XSL transformations

2009-01-28T08:54:00.004-08:00

You can define parameters for your XSL transformation when adding the XSL Transformation server behavior to a web page. A parameter controls how XML data is processed and displayed. For example, you might use a parameter to identify and list a specific article from a news feed. When the page loads in a browser, only the article you specified with the parameter appears.

To add an XSLT parameter to an XSL transformation:

Open the XSL Transformation dialog box. You can do this by double-clicking an XSL Transformation server behavior in the Server Behaviors panel (Window > Server Behaviors), or by adding a new XSL Transformation server behavior. For instructions, see Inserting XSLT fragments in dynamic pages.
In the XSL Transformation dialog box, click the Plus (+) button next to XSLT Parameters.
In the Add Parameters dialog box, enter a name for the parameter in the Name text box. The name can only contain alphanumeric characters. It cannot contain spaces.
Do one of the following:
- If you want to use a static value, enter it in the Value text box.
- If you want to use a dynamic value, click the dynamic icon next to the Value text box, complete the Dynamic Data dialog box, and click OK. For more information, click the Help button in the Dynamic Data dialog box.
In the Default Value text box, enter the value you want the parameter to use if the page receives no run-time value.
Click OK.
To edit an XSLT parameter:
1. Open the XSL Transformation dialog box. You can do this by double-clicking an XSL Transformation server behavior in the Server Behaviors panel (Window > Server Behaviors), or by adding a new XSL Transformation server behavior. For instructions, see Inserting XSLT fragments in dynamic pages.
2. Select a parameter from the XSLT parameters list.
3. Click the Edit button.
4. Make your changes and click OK.
To delete an XSLT parameter:
1. Open the XSL Transformation dialog box. You can do this by double-clicking an XSL Transformation server behavior in the Server Behaviors panel (Window > Server Behaviors), or by adding a new XSL Transformation server behavior. For instructions, see Inserting XSLT fragments in dynamic pages.
2. Select a parameter from the XSLT parameters list.
3. Click the minus (-)button.

Creating conditional XSLT regions

2009-01-28T08:54:00.003-08:00

You can use Dreamweaver to create simple conditional regions or multiple conditional regions on an XSLT page. You can make a selection in Design view and apply a conditional region to the selection, or you can just insert a conditional region wherever the insertion point is in the document.

For example, if you wanted to display the word "Unavailable" next to the price of an item when the item is unavailable, you could type the word "Unavailable" on the page, select it, and then apply a conditional region to the selected text. Dreamweaver surrounds the selection with tags, and only displays the word on the page when the data match the conditions of the conditional expression.

To create a conditional XSLT region:

Select Insert > XSLT Objects > Conditional Region, or Insert > XSLT Objects > Multiple Conditional Region.
In the Conditional Region or Multiple Conditional Region dialog box, enter the conditional expression you want to use for the region.
For more information, click the Help button in the dialog box.
Click OK.

Editing a Conditional Region XSLT object

2009-01-28T08:54:00.001-08:00

After you’ve added a conditional XSLT region to your page, you can make changes to it using the Property inspector.

To edit a Conditional Region XSLT object:

Select the object by clicking the gray tab that surrounds the conditional region.
In the Property inspector (Window > Properties), edit your conditional expression in the Test text box.

Inserting XSL comments

2009-01-28T08:53:00.004-08:00

You can add XSL comment tags to a document, or you can wrap a selection in XSL comment tags.

To add XSL comment tags to a document:

Do one of the following:
- In Design view, select Insert > XSLT Objects > XSL Comment, type the contents of the comment (or leave the text box blank), and click OK.
- In Code view, select Insert > XSLT Objects > XSL Comment.

To wrap a selection in XSL comment tags:

Switch to Code view (View > Code)
Select the code you want to comment.
On the Coding toolbar, click the Apply Comment button and select Apply Comment.

Performing XSL transformations on the client

2009-01-28T08:53:00.003-08:00

You can perform XSL transformations on the client without the use of an application server. When you do so, a browser does the work of transforming the XML data, instead of an application server. You can use Dreamweaver to create such a page, however, client-side transformations require manipulation of the XML file containing the data you want to display. Additionally, client-side transformations will only work in modern browsers.

Macromedia recommends that you read About client-side XSL transformations before proceeding with any of the following procedures.

Workflow for performing client-side XSL transformations

2009-01-28T08:53:00.001-08:00

This section provides a list of steps you need to follow to perform client-side XSL transformations, and refers you to the sections in the documentation that elaborate on each procedure.

To perform client-side XSL transformations, follow these steps:

Set up a Dreamweaver site. See Setting Up a Dreamweaver Site.
Do one of the following:
- In your Dreamweaver site, create an entire XSLT page. See Creating entire XSLT pages.
- Convert an existing HTML page to an entire XSLT page. See Converting HTML pages to XSLT pages
If you haven’t already done so, attach an XML data source to the page. See Attaching XML data sources. The XML file that you attach must reside in the same directory as the XSLT page.
Bind your XML data to the XSLT page. See Displaying XML data in XSLT pages.
If appropriate, add a Repeat Region XSLT object to the table or table row that contains the XML data placeholder(s). See Displaying repeating XML elements.
Attach the XSLT page to the XML page. See Linking XSLT and XML files.
Post both the XML page and the linked XSLT page to your web server.
View the XML page in a browser. When you do so, the browser transforms the XML data, formats it with the XSLT page, and displays the styled page in the browser.

Linking XSLT and XML files

2009-01-28T08:52:00.001-08:00

Once you have an entire XSLT page with dynamic content placeholders for your XML data, you must insert a reference to the XSLT page in the XML page.

NOTE

To link an XSLT page to an XML page:

Open the XML file that you want to link to your XSLT page.
Select Commands > Attach an XSLT Stylesheet.
In the Attach an XSLT Stylesheet dialog box, click the Browse button, browse to the XSLT page you want to link to, select it, and click OK.
Click OK to close the Attach an XSLT Stylesheet dialog box.

Applying styles to XSLT fragments

2009-01-28T08:51:00.002-08:00

When you create an entire XSLT page (that is, an XSLT page that contains and tags), you can display XML data on the page and then format the data like any other piece of content using the Property inspector or the CSS Styles panel. When you create an XSLT fragment for insertion in a dynamic page, however (for example, a fragment for insertion in an ASP, PHP, or Cold Fusion page), the rendering of styles in the fragment and in the dynamic page becomes more complicated. Although you work on an XSLT fragment separately from the dynamic page, it is important to remember that the fragment is intended for use within the dynamic page, and that the output from the XSLT fragment ultimately resides somewhere within the tags of the dynamic page. Given this workflow, it is important to make sure that you do not include elements (such as style definitions or links to external style sheets) in XSLT fragments. Doing so will cause the application server to place these elements into the of the dynamic page, thereby generating invalid markup.

For example, let’s say you’re creating an XSLT fragment for insertion in a dynamic page, and you want to format the fragment using the same external style sheet as the dynamic page. If you attach the same style sheet to the fragment, the resulting HTML page will contain a duplicate link to the style sheet (one in the section of the dynamic page, and another in the section of the page, where the content of the XSLT fragment appears). Instead of this approach, you should use Design-time style sheets to reference the external style sheet.

When formatting the content of XSLT fragments, Macromedia recommends that you use the following workflow:

First, attach an external style sheet to the dynamic page. (This procedure follows best practices for applying styles to the content of any web page).
Next, attach the same external style sheet to the XSLT fragment as a Design-time style sheet. As the name implies, Design-time style sheets only work in the Dreamweaver Design view. For more information, see Using Design-Time style sheets.

Once you have completed the previous steps you can apply existing styles or create new styles in your XSLT fragment using the same style sheet that you’ve attached to your dynamic page. You will have cleaner HTML output (because the reference to the style sheet is only valid while working in Dreamweaver), and the fragment will still display the appropriate styles in Design view. Additionally, all of your styles will be applied to both the fragment and the dynamic page when you view the dynamic page in Design view, or preview the dynamic page in a browser.

NOTE

If you preview the XSLT fragment in a browser, the browser does not display the styles. Instead you should preview the dynamic page in the browser to see the XSLT fragment within the context of the dynamic page.

For more information on using CSS to format XSLT fragments, see www.macromedia.com/go/dw_xsl_styles.

Troubleshooting XSL transformations

2009-01-28T08:51:00.001-08:00

If you are having trouble getting your XSL transformations to work, a troubleshooting guide with the answers to many frequently asked questions is available at www.macromedia.com/go/dw_xsl_faq.

Setting the Locate XML Source dialog box options

2009-01-28T08:50:00.004-08:00

The purpose of this dialog box is to specify an XML data source for the XLST page.

To set the dialog box options:

Do one of the following:
- Select Attach a local file, click the Browse button, browse to a local XML file on your computer, and click OK.
- Select Attach a remote file, enter the URL of an XML file on the Internet (such as one coming from an RSS feed), and click OK.

Clicking the Cancel button generates a new XSLT page with no attached XML data source. For information on attaching XML data sources, see Attaching XML data sources.

Setting the Attach an XSLT Stylesheet dialog box options

2009-01-28T08:50:00.003-08:00

The purpose of this dialog box is to attach an XSLT style sheet to an XML file.

To set the dialog box options:

Enter the path and filename of the XSLT style sheet, or click Browse and select it.

Setting XPath Expression Builder (Dynamic Text) dialog box options

2009-01-28T08:50:00.001-08:00

The purpose of this dialog box is to select a value in your XML data to display on your page. Dreamweaver inserts a tag at the insertion point. The advantage of using this method instead of dragging values from the XML schema tree is that you can format the value that is displayed.

One of the advantages of the XPath Expression Builder is that it identifies the current context based on your position in the XSL file when the dialog box is opened. The current context is in boldface type in the XML schema tree. As you make selections within this dialog box, it generates the correct XPath statements relative to your current context. This simplifies the process of writing correct XPath expressions for both beginners and advanced users.

XPath (XML Path Language) is a non-XML syntax for addressing portions of an XML document. It is used mostly as a query language for XML data, just as the SQL language is used to query databases. For more information on XPath, see the XPath language specification on the W3C website at www.w3.org/TR/xpath.

It is important to note that this dialog box is designed to help you build simple XPath expressions to identify a specific node. It does not allow you to edit the expressions by hand. If you need to create complex expressions, use this dialog box to get started and then customize your expressions in Code view or with the Property inspector.

To select a value to display on your page:

In the XPath Expression Builder (Dynamic Text) dialog box, select any node in the XML schema tree.
Dreamweaver writes the correct XPath expression in the Expression text box to identify the node.

NOTE

If you select a different node in the XML schema tree, the expression changes to reflect your choice.

In the following example, you want to display the price subelement of the item node:
This selection would insert the following code in your XSLT page:
```
 
```
If you want, select a formatting option from the Format pop-up menu.
Formatting a selection is useful when the value of your node returns a number. Dreamweaver provides a predefined list of formatting functions. For a complete list of available formatting functions and examples, see the Reference panel.

In the following example, you want to format the price subelement as a currency with two decimal places:
1. These options would insert the following code in your XSLT page:
```
 
```
2. Click OK.
3. To display the value of each node in the XML file, apply a repeat region to the element containing the dynamic text (for example, an HTML table row or a paragraph).
  For more information, see Displaying repeating XML elements.
For more information and examples on selecting nodes to return a value, see the section in the Reference panel.

Setting the XPath Expression Builder (Repeat Region) dialog box options

2009-01-28T08:48:00.000-08:00

The purpose of this dialog box is to select a node to repeat over and, optionally, to filter the results. If you have content selected when this dialog box is invoked, your content will be wrapped inside an block. If you do not have content selected, the block will be entered at the insertion point of your cursor.

It is important to note that this dialog box is designed to help you build simple XPath expressions for repeat regions. It does not allow you to edit the expressions by hand. If you need to create complex expressions, use this dialog box to get started and then customize your expressions in Code view or with the Property inspector.

To select a node to repeat:

In the XPath Expression Builder (Repeat Region) dialog box, select the item to repeat in the XML schema tree.
Dreamweaver writes the correct XPath expression in the Expression text box to identify the node.

NOTE

Repeating items are identified with a Plus (+) symbol in the XML schema tree.

In the following example, you want to repeat over each item node within the XML file.

When you click OK, the following code is inserted in your XSLT page:

    Content goes here

In some cases, you may want to work with a subset of the repeating nodes--for example, you may only want items where an attribute has a specific value. In this case, you need to create a filter.

To filter the data to be repeated:

In the XML schema tree, select a node to repeat.
Click the Build Filter expander button.
Click the Plus (+) button.
Dreamweaver creates an empty filter.
Enter the filter criteria in the following fields:
Filter By specifies the repeating node that contains the data you want to filter by. The pop-up menu provides a list of ancestor nodes relative to the node you selected in the XML schema tree.

Where specifies the attribute or subelement of the Filter By node that will be used to limit the results. You can select an attribute or subelement from the pop-up menu, or you can enter your own XPath expression in this field to identify children that exist deeper within the schema tree.

Operator specifies the comparison operator to use in the filter expression.

Value specifies the value to check for in the Filter By node. Enter the value. If dynamic parameters are defined for your XSLT page, you can select one from the pop-up menu.
To specify another filter, click the Plus (+) button again.
As you enter values or make selections in the pop-up menus, Dreamweaver changes the XPath expression in the Expression text box.

In the following example, you want to restrict the resultset to those item nodes where the value of the @available attribute is true.

When you click OK, the following code is inserted in your XSLT page:

      Content goes here  NOTE   You need to surround string values such as true in quotes. Dreamweaver encodes the quotes for you (') so that they are entered as valid XHTML.

You can create more complex filters that allow you to specify parent nodes as part of your filter criteria. In the following example, you want to restrict the resultset to those item nodes where the store’s @id attribute is equal to 1 and the item’s price node is greater than 5.

When you click OK, the following code is inserted in your XSLT page:

    Content goes here

For more information and examples of repeat regions, see the section in the Reference panel.

Setting the Conditional Region dialog box options

2009-01-28T08:46:00.004-08:00

The purpose of this dialog box is to write a simple conditional expression to insert into your XSLT page. If content is selected when you open this dialog box, the content will be wrapped in an block. If you do not have content selected, the block will be entered at the insertion point.

This dialog box provides a way to create a simple conditional expression. It is recommended that you use the dialog box to get started and then customize the expression in Code view.

The element is similar to the if statement in other languages. The element provides a way for you to test a condition and take a course of action based on the result. The element allows you to test an expression for a single true or false value.

To insert a conditional region:

In the Conditional Region dialog box, enter the condition.
In the following example, you want to test to see if the context node’s @available attribute value is true.
1. Click OK.
  The following code is inserted in your XSLT page:
```
    Content goes here  NOTE   You need to surround string values such as true in quotes. Dreamweaver encodes the quotes for you (') so that they are entered as valid XHTML.
 
```
In addition to testing nodes for values, you can use any of the supported XSLT functions in any conditional statement. The condition is tested for the current node within your XML file. In the following example, you want to test for the last node in the resultset:

For more information and examples on writing conditional expressions, see the section in the Reference panel.

Setting the Multiple Conditional Region dialog box options

2009-01-28T08:46:00.003-08:00

This dialog box provides a way to create a simple conditional expression. It is recommended that you use the dialog box to get started and then customize the expression in Code view.

The element is similar to the case statement in other languages. The element provides a way for you to test a condition and take a course of action based on the result. The element allows you to test for multiple conditions.

To insert a multiple conditional region:

In the Multiple Conditional Region dialog box, enter the first condition.
In the following example, you want to test to see if the context node’s price subelement is less than 5.

Click OK.

In the example, the following code is inserted in your XSLT page:

           Content goes here               Content goes here

To insert another condition, place the insertion point in Code view between tag pairs or just before the tag, and then insert a conditional region (Insert > XSLT Objects > Conditional Region).
After you specify the condition and click OK, Dreamweaver inserts another tag in the block.

For more information and examples on writing conditional expressions, see the sections in the Reference panel.

Setting Repeat Region (XSL) properties

2009-01-28T08:46:00.001-08:00

The purpose of this Property inspector is to select a different XML node to repeat to create the repeat region.

To select a different XML node:

In the Select text box, enter a new node, and then press the lightning bolt icon and select the node from the XML schema tree that appears.

Setting Conditional Region (If) properties

2009-01-28T08:13:00.002-08:00

The purpose of this Property inspector is to change the condition used in a conditional region in your XSL page. The conditional region tests the condition and takes a course of action based on the result.

To change the condition used in the conditional region:

In the Test text box, enter a new condition, and then press Enter.

Setting Conditional Region (When) properties

2009-01-28T08:13:00.001-08:00

The purpose of this Property inspector is to change the condition used in a multiple conditional region in your XSL page. The multiple conditional region tests the condition and takes a course of action based on the result.

To change the condition used in the multiple conditional region:

In the Test text box, enter a new condition, and then press Enter.

Specifying a missing character entity

2009-01-28T08:12:00.002-08:00

In XSLT, some characters are not allowed in certain contexts. For example, you cannot use the less than sign (<) and the ampersand (&) in the text between tags or in an attribute value. The XSLT transformation engine will give you error if those characters are used incorrectly. To solve the problem, you can specify character entities to replace the special characters.

A character entity is a string of characters that represents other characters. Character entities are either named or numbered. A named entity begins with an ampersand (&) followed by the name or characters, and ends with a semicolon (;). For example, < represents the left angle bracket character (<). Numbered entities also start and end the same way, except that a hash sign (#) and a number specifies the character.

XSLT has the following five predefined entities:

Character	Entity Code
< (less-than)	<
& (ampersand)	&
> (greater-than)	>
" (quote)	"
‘ (apostrophe)	'

If you use other character entities in an XSL file, you need to define them in the DTD section of the XSL file. Dreamweaver provides several default entity definitions that you can see at the top of an XSL file created in Dreamweaver. These default entities cover a broad selection of the most commonly used characters.

Dreamweaver checks the XSL file for undefined entities when you preview your XSL file in a browser. If it finds an undefined entity, Dreamweaver notifies you in a message box.

If you preview an XML file attached to an XSLT file or if you preview a server-side page with an XSLT transformation, the server or browser (instead of Dreamweaver) notifies you of an undefined entity. The following is an example of a message you may get in Internet Explorer when you request an XML file transformed by an XSL file with a missing entity definition:

Reference to undefined entity 'auml'. Error processing resource 'http://localhost/testthis/list.xsl'. Line 28, Position 20

-------------------^

To correct the error in your page, you’ll need to add the entity definition to your page by hand.

To specify a missing entity definition:

Look up the missing character in the character entity reference page on the W3C website at www.w3.org/TR/REC-html40/sgml/entities.html.
This web page contains the 252 allowed entities in HTML 4 and XHTML 1.0.

For example, if the character entity Egrave is missing, search for "Egrave" on the W3C web page. You will find the following entry:
```
 
```
Make a note of the entity name and entity code in the entry.
In the example, Egrave is the entity name, and &#200 is the entity code.
With this information, switch to Code view in Dreamweaver and enter the following entity tag at the top of your XSL file (following the Doctype declaration and with the other entity tags):
```
entityname "entitycode;"> 
```
In the example, you would enter the following entity tag:
```
 
```
Save your file.

If you repeatedly use the same character entities, you may want to permanently add their definitions in the XSL files Dreamweaver creates by default when you use File > New.

To add entity definitions to the XSL files Dreamweaver creates by default:

Locate the following configuration file in the Dreamweaver application folder and open it in any text editor:
Configuration/DocumentTypes/MMDocumentTypeDeclarations.xml
Locate the declaration called mm_xslt_1:
```
 
```
Enter the new entity tag or tags in the list of entity tags, as follows:
```
entityname "entitycode;"> 
```
Save the file and relaunch Dreamweaver.

Using Web Services

2009-01-28T08:12:00.001-08:00

Web services are an emerging technology that allow web pages to access distributed applications. By offering both access to information and application functionality as a service, web services can be delivered and paid for as streams of services that allow ubiquitous access from any platform. The web page that connects to the web service is commonly known as a consumer, and the service itself is known as a publisher. Macromedia Dreamweaver 8 lets you create pages and sites that are consumers of web services. Dreamweaver currently supports the creation of web-service consumers using Macromedia ColdFusion MX, ASP.NET, and Java Server Pages (JSP) document types. Specifically, Dreamweaver allows you to perform the following web service development tasks:

Select web services available on the Internet.
Generate a web service proxy that allows the web page to communicate with the web service publisher.
The proxy (also known as an abstraction class) contains the fields, methods, and properties of the web service, and makes them available to the locally hosted page. When you generate a proxy for your page, Dreamweaver lets you view them in the Components panel.
Drag methods and data types into the page’s code.

Before you create a web page that uses a web service, you must be familiar with the underlying server technology of the application you want to use and the programming constructs that the application requires.

Dreamweaver allows you to author web pages that can access web services and make use of the functionality the services provide. In addition, you can create and publish web services for deployment using Macromedia ColdFusion MX.

This chapter contains the following sections:

About web services

About proxy generators

Adding a web service proxy using the WSDL description

Adding a web service to a page

Editing the UDDI web service site list

About web services

2009-01-28T08:11:00.004-08:00

Web services allow applications to communicate and share information across the Internet, regardless of operating system or programming language. Examples of web services, and the information and functionality they provide, include the following:

User authentication and authorization
Credit card validation
Financial markets services that return stock prices associated with specified ticker symbols
Purchasing services that allow users to order products online
Information services that provide news or other information types based on a selected interest, location, or other personal information

By providing functionality as a service that a web page connects to and uses as needed, web services give developers and service providers greater flexibility in designing and deploying powerful, distributed applications.

Web services consist of the following basic components:

Service publishers provide hosted applications and make them available for use. Web services can be provided either for free, or as a fee-based service.
Service brokers maintain a registry of service providers with descriptions of service offerings and links to their applications.
Service consumers are the web pages that access and use the remote web service.

This section covers the following conceptual topics:

The Dreamweaver web service workflow
Finding web service publishers
Web service software components
Web service references
Obtaining additional proxy generators

The Dreamweaver web service workflow

2009-01-28T08:11:00.003-08:00

To create a page or site that is a consumer of a web service using Dreamweaver, you must perform the following tasks:

Install and configure a proxy generator.
Proxy generators generate a web service proxy, a software component that a web page uses to communicate with the web service publisher. The web service proxy is generated from the Web Service Description Language (WSDL) that describes the web service. Depending on the server technology you want to develop web service consumers for, you may need to install and configure a proxy generator that supports that technology.

Dreamweaver comes pre-configured with AXIS, the Apache SOAP proxy generator that supports JSP web service development. If you are developing ColdFusion 6 pages, the web service proxy generator is included in the ColdFusion server. Establishing a connection to the ColdFusion server gives you access to the proxy generator.

If you are developing web service pages for use with ASP.NET, you must install the ASP.NET SDK, which is available from Microsoft.

For information on installing and configuring a proxy generator not supplied with Dreamweaver, see About proxy generators.
Using a browser, view a web-based registry of web services.
There are several sources of web services, ranging from web service registry sites to simple lists. The registries use UDDI, a standard that lets service providers and requestors find and transact with one another. UDDI allows businesses to locate services on the web that meet their needs. For example, using UDDI you can specify certain criteria such as the lowest price for a certain service, or that specific information be returned.

For more information see Setting the UDDI Site dialog box options.
After locating and selecting a web service that provides the functionality you need, enter the URL of the WSDL in the Adding a Web Service dialog box.
For more information see Setting the Web Services Chooser dialog box options.
Generate a proxy for the web service from the WSDL description of the service publisher.
To embed a web service into a web page, you must create a proxy. The proxy provides the web page with the necessary information to communicate with the web service, and access the methods the web service provides.

To create a proxy from the WSDL file, use a proxy generator. After you create the proxy, you can install it on either of the following:
- The local computer where you are developing the web service consumer.
- The server computer running the application server. To deploy the web page and have it communicate with the web service publisher you must install the proxy on the server.
For more information, see About proxy generators.
Using Dreamweaver, add the web service to a page and edit the necessary parameters and methods to make use of the service’s functionality.
For more information, see Adding a web service to a page.

Finding web service publishers

2009-01-28T08:11:00.001-08:00

Web services themselves are made available by service publishers. Typically, the service publisher makes its web service available through a web-based registry that maintains a directory of available services that you can access. A number of websites provide such a directory, including:

X Methods at http://www.xmethods.net
IBM Business Registry at https://uddi.ibm.com/ubr/registry.html
Microsoft UDDI registry at http://uddi.microsoft.com/default.aspx

These registries use the Universal Description, Discovery and Integration (UDDI) service, an open, e-commerce service registry that provides a forum for businesses to describe themselves and the goods or services they can provide to other businesses. A group of companies, called operators, maintain the registry. The operators have pledged to share all public information about registrants among themselves and with users of the service, and to maintain inter-operability among the multiple peer nodes of the UDDI service network. In addition to public web services, there are also private UDDI registries available on a subscription basis.

The UDDI specification is based on existing Internet standards, ensuring that it is platform and implementation neutral.

Web service software components

2009-01-28T08:10:00.006-08:00

For a web page to access and use a web service, it must communicate with the service and have a description of the functionality the service provides, the available methods that it can invoke, and the parameters the service returns. The Web Service Description Language (WSDL) is an XML-based description of the service. Each web service provides a WSDL that describes how to bind to the service, the available methods that the web page can invoke, and the data inputs and outputs. The WSDL can reside in a file, or it can be generated by the web service at runtime.

Communication between the web page requesting the service and the web service itself uses the Simple Object Access Protocol (SOAP). SOAP is an XML-based protocol that lets a web client access and invoke the web service’s methods and parameters.

Web service references

2009-01-28T08:10:00.005-08:00

To learn more about web services, and the underlying technologies that make them possible, visit the following websites:

WSDL specification at http://www.w3.org/TR/wsdl
UDDI specification at http://www.uddi.org/specification.html
XML specification at http://www.w3.org/TR/REC-xml
SOAP specification at http://www.w3.org/TR/SOAP/

Obtaining additional proxy generators

2009-01-28T08:10:00.003-08:00

If you want to install a proxy generator that is not supplied with Dreamweaver, you must obtain the proxy generator and any related software components from the vendor. You should be able to download all the necessary files from the vendor’s website.

Some proxy generators create proxies that depend on other software libraries, which must be appropriately installed so the proxy generator can access them. For example, the AXIS proxy generator creates proxies that depend on the Apache SOAP library, which, in turn, depends on other software libraries (note that all the necessary software needed to use AXIS is installed by default with Dreamweaver). When selecting a proxy generator, consult the provided documentation, and ensure that you have all the required software components and libraries, so that you can properly install and configure them.

After you have properly installed and configured the proxy generator, you must configure it to work with Dreamweaver.

NOTE

Currently, web services development with Dreamweaver is limited to the Windows environment. To develop pages that access web services on the Macintosh, you must use a separate application server running either Windows NT/2000/XP or UNIX on which to run the web service proxy and its application environment.

Adding a web service proxy using the WSDL description

2009-01-28T08:10:00.001-08:00

After you have specified a proxy generator (see About proxy generators) and configured the web service server models you want to support, you need to find a web service that provides the desired functionality and generate a proxy for that service.

To select a web service and generate a proxy from its WSDL file:

Open the page that you want to add the web service to.
Select Window > Components to open the Components panel.
In the Components panel, select Web Services from the pop-up menu in the upper left of the panel, click the Plus (+) button, and select Add Using WSDL.
The Add Using WSDL dialog box appears.
Specify the URL of the WSDL file you want to use.
If you know the URL of the WSDL file, enter it in the URL of the WSDL text box.

If you don’t know the URL of the WSDL file, you can browse a directory of web services. When you find the web service you want, copy and paste the URL of the web service into the WSDL edit box. To start a web browser, click the UDDI browse button and select one of the listed web service registries. Dreamweaver will start the browser and open the selected registry. Locate the web service you want to use, and copy the URL of its WSDL file to the Clipboard (Control+C in Windows or Command+C on the Macintosh). Return to the Web Services Chooser and paste the URL into the dialog box.

You can edit the list of web service registries to include additional web service directories or specific web service providers. For more information, see Editing the UDDI web service site list.
Select a proxy generator that supports your desired web services server model from the Proxy Generator pop-up menu.
Make sure the proxy generator is installed and configured on your system. For more information, see About proxy generators.
Click OK.
The proxy generator creates a proxy for the web service and introspects it. Introspection is the process where the proxy generator queries the internal structure of the web service proxy, and makes its interfaces, methods, and properties available through Dreamweaver.

The web service is now available for use in the site, and appears in the Components panel. You can now add the web service to a page. For more information, see Adding a web service to a page.

Adding a web service to a page

2009-01-28T08:09:00.003-08:00

After selecting a web service, generating its proxy, and adding it to the Components panel, you can insert it into a page.

The illustration below shows the Components panel with the web service proxy Helloworld added. The Helloworld proxy provides one method, sayHello, which prints "Hello World."

The following example instantiates the HelloWorld web service using ColdFusion. To learn more about creating a web services, and to see additional examples using .NET and JSP, visit the Macromedia Support Center at: www.macromedia.com/go/creating_web_services.

To add a web service to a page:

In the Document window, in Code view, drag the sayHello method into the page’s HTML.
Dreamweaver adds the method and dummy parameters to the page.
Edit the inserted code with appropriate service instance names, data types, and parameter values, as required by the web service. The web service should provide descriptions of the data types and parameter values.
In the ColdFusion example shown below, the web service is enclosed by the tags. When developing a web service in ColdFusion, use to instantiate the web service and invoke its methods.
```
           
```
If you want to bind a return value to a visual element, switch to Design view and place a visual element on the page that can accept data binding. Then switch back to Code view and enter the appropriate code to bind the returned value to the visual element. When creating web services, refer to the technology provider’s documentation for the proper syntax with which to both instantiate the service and display the returned values to the page.
In this example, the value returned for the variable aString is output using the ColdFusion tag. This will display the sentence "The web service says: Hello world!" to the page.
```
        The web service says: #aString#   
```

When you deploy web pages to a production server, Dreamweaver automatically copies the pages, the proxy, and any necessary libraries to the web server.

NOTE

If you develop the application with a proxy that is installed on a separate computer from the one where you developed the pages, or if you use a site management tool that does not copy all of the related files to the server, you must be sure to deploy both the proxy and any dependent library files.Otherwise, your pages cannot communicate with the web service application.

Editing the UDDI web service site list

2009-01-28T08:09:00.001-08:00

The Web Service Chooser provides a list of UDDI-based web service directories from which you can select web services. You can edit this list to add or delete web service directories. For more information, see Finding web service publishers.

To edit the web service site list:

In Dreamweaver, select Window > Components to open the Components panel.
In the Components panel, select Web Services from the pop-up menu in the upper left of the panel, and then click the Plus (+) button to add a web service.
The Add Using WSDL dialog box appears.
In the Web Services Chooser, click the globe icon and select Edit UDDI Site List from the pop-up menu.
The UDDI Sites dialog box appears.
From the UDDI Sites dialog box you can add new web service sites, edit the name and URL of existing sites, and remove unwanted sites.
- To add a new site, or modify and existing one, click the New or Edit button and complete the dialog box that displays.
- To remove an existing site, select it in the list and click the Remove button.

Setting the Web Services Chooser dialog box options

2009-01-28T08:08:00.006-08:00

This dialog box lets you select a web service and generate a proxy that lets the page access the service.

To set the Web Services Chooser dialog box options:

Set the following options:
URL of WSDL file Enter either the URL or local file path of the WSDL file. This information is read as input by Dreamweaver, and is used to generate the proxy and scripting information for the web service.

Proxy Generator Select a proxy generator that supports your chosen document type to generate a web service proxy.

Explorer button Select from a menu that contains plain-English names of URLs to UDDI registries and other significant repositories of WSDL files. After you select a menu item, a browser appears and opens the selected URL. The Choosing Edit Browser List opens the dialog box for editing browser preferences.
Click OK.

Setting the Proxy Generators dialog box options

2009-01-28T08:08:00.005-08:00

This dialog box lets you define new proxy generators, or modify, delete, or duplicate existing ones.

To define, modify, or remove a proxy generator:

Perform any of the following actions:
- To add a proxy generator to the list, click New and complete the dialog box that appears.
  For more information, see Setting the Default Proxy Generator dialog box options.
- To delete a proxy generator from the list, select it in the list and click Remove.
- To modify a proxy generator, select it in the list and click Edit. Make changes in the resulting dialog box.
  For more information, see Setting the Default Proxy Generator dialog box options.
- To create a copy of a proxy generator, select it in the list and click Duplicate.
Click Done.

Setting the Default Proxy Generator dialog box options

2009-01-28T08:08:00.003-08:00

This dialog box lets you set the properties of a default proxy generator.

To configure the default proxy generator:

Set the following properties:
Name The name of the proxy generator instance to appear in the pop-up menu.

Server Models Supported The list of server models that the proxy generator supports. You can edit the list by using the Plus (+) and Minus (-) buttons.

Clicking the Plus (+) button displays the Select Server Models dialog box. Select a server model from the list of available server models, and click OK.

Generate Proxy Command Generate proxy source code from WSDL information. The following tokens can be used in the proxy generator commands:

Compile Proxy Command Compiles the proxy source code to executable code.

Introspect Compiled Proxy Introspect the compiled proxy by selecting an introspector from the pop-up menu.

Destination Folder Folder in which to put the compiled web service proxy and its source code.
Click OK.

Setting the Select Server Model dialog box options

2009-01-28T08:08:00.001-08:00

The Select Server Model dialog box lets you to select the server models to support with the specified proxy generator.

To select a server model:

Select a server model from the list. You can select multiple server models by holding the Control key and selecting from the list.
Click OK.

Setting the UDDI Site dialog box options

2009-01-28T08:07:00.002-08:00

The UDDI Sites dialog box lets you add, edit, or remove UDDI directories so that you can easily browse for web services.

To add a new site, or edit an existing one:

Click the New button to display the New UDDI Site dialog box, or the Edit button to display the Edit UDDI Site dialog box.
If you know the name and URL of a UDDI website, enter that information.
You can also start a web browser to locate UDDI sites by clicking the browser button (the globe icon) next to the Address text box.
When you have entered the name and URL of a UDDI website, click OK.
The new or modified UDDI site appears in the list of sites in the UDDI Sites dialog box.
Click Done.

To remove a site:

Select a site from the list and click the Remove button.
Click Done

Setting the Add Using Proxy Classes dialog box

2009-01-28T08:07:00.001-08:00

This dialog box lets you select a local .NET DLL or JSP Reader to introspect web service proxies when using the .NET or JSP development framework.

To select a proxy class reader:

Enter the location of the proxy class reader in the text box.
You can browse for the file by clicking the Browse button to the right of the text box.
Select a proxy reader you want to use from the pop-up menu.
There are two default proxy readers:
- The .NET DLL Reader for ASP .NET document types
- The Java Class Reader for JSP document types
Click OK.

Adding Custom Server Behaviors

2009-01-21T10:26:00.000-08:00

Macromedia Dreamweaver 8 comes with a set of built-in server behaviors that lets you easily add dynamic capabilities to a site. If you want to extend Dreamweaver’s functionality, you can create new server behaviors to suit your development needs, or obtain server behaviors from the Macromedia Exchange website.

This chapter contains the following sections:

About custom server behaviors

Installing third-party server behaviors

Using the Server Behavior Builder

Using parameters in server behaviors

Positioning code blocks

Creating a dialog box for a custom server behavior

Editing and modifying server behaviors

Reference

Reference

2009-01-21T10:23:00.000-08:00

This section provides information about the following dialog boxes introduced in this chapter:

Setting the Edit Server Behaviors dialog box options

2009-01-21T10:22:00.000-08:00

This dialog box let you select a server behavior to edit.

To edit a server behavior:

Select a document type and server behavior.
Click Edit.
The Edit Server Behavior dialog box appears, letting you edit the server behavior. For more information, see Editing and modifying server behaviors.

Setting the Generate Behavior Dialog Box dialog box options

2009-01-21T10:21:00.002-08:00

This dialog box generates a dialog box for a custom server behavior that requires input from the user. It is also used to edit such a dialog box.

When this dialog box opens, it lists all of the supplied parameters defined in the code. For more information, see Creating a dialog box for a custom server behavior.

To create a dialog box for user input:

To change the display order of the dialog box controls, select a parameter and click the up and down arrows.
To change a parameter’s control, select the parameter and selecting another control in the Display As column.
Click OK.

Dream weaver generates a dialog box for your custom server behavior, or it updates an existing dialog box.

Setting the Create a New Code Block dialog box options

2009-01-21T10:21:00.001-08:00

The purpose of this dialog box is to name and create a code block in the Server Behavior Builder.

To name and create a code block using the Server Behavior Builder:

Enter a name in the text box and click OK.

Setting the Insert Parameter in Code Block dialog box options

2009-01-21T10:20:00.000-08:00

This dialog box lets you replace every instance of a selected string in a code block containing parameter markers.

To replace every instance of a string within a code block:

Enter a parameter name.
Example: Session
Click OK.

Dreamweaver replaces every instance of the selected string in the code block with a parameter marker (for example, @@Session@@).

Setting the Server Behavior Builder dialog box options

2009-01-21T10:17:00.000-08:00

To complete the Server Behavior builder dialog box:

Start a code block by clicking the Plus (+) button, entering a name for the code block, and clicking OK.
One convention is to name code blocks as follows:
```
NameOfBehavior_NameOfBlock 
```
Here is an example:
```
MoveToRecord_Init
```
In the Code Block text area, enter the runtime code to be inserted in the page.
The runtime code must be a single tag block or script block. If you need to insert multiple tags or script blocks, split them into separate code blocks. You can also copy and paste code from other pages.

For more information, see the following sections:
- Using parameters in server behaviors
- Positioning code blocks
- Repeating code blocks
- Coding guidelines
Specify where to insert the code block in the page’s HTML source code by using the Insert Code pop-up menu.
Code blocks are inserted relative to tags in the page or relative to a tag selected by the page designer. For more information, see Positioning code blocks.
To specify more advanced settings, click Advanced.
Once you specify the source code and insert location for each code block, the server behavior is completely defined. In most cases, you don’t need to specify any additional information.

If you are an advanced user, you may want to modify additional parameters by clicking the Advanced button in the Server Behavior Builder. The builder expands to display several new options.

Identifier specifies whether or not the code block should be treated as an identifier.

By default, every code block is an identifier. If Dreamweaver finds an identifier code block anywhere in a document, it lists the behavior in the Server Behaviors panel. Use the Identifier checkbox to specify whether the code block should be treated as an identifier.

At least one of the server behavior’s code blocks must be an identifier. A code block should not be an identifier if one of the following conditions applies: the same code block is used by some other server behavior; or the code block is so simple that it might occur naturally on the page.

Server Behavior Title specifies the title of the behavior in the Server Behaviors panel.

When the page designer clicks the Plus (+) button on the Server Behaviors panel, the new server behavior’s title will appear in the pop-up menu. When a designer applies an instance of a server behavior to a document, the behavior appears in the list of applied behaviors in the Server Behaviors panel. Use the Server Behavior Title text box to specify the contents of the Plus (+) pop-up menu and the list of applied behaviors.

The initial value in the box is the name you supplied in the New Server Behavior dialog box. As parameters are defined, the name is automatically updated so that the parameters appear inside parentheses after the server behavior name.
```
Set Session Variable (@@Name@@, @@Value@@)
```
If the user accepts the default value, everything before the parentheses will appear in the Plus (+) pop-up menu (for example, Set Session Variable). The name plus the parameters will appear in the list of applied behaviors--for example, Set Session Variable ("abcd", "5").

Code Block to Select specifies what code block is selected when the user selects the behavior in the Server Behaviors panel.

When you apply a server behavior, one of the code blocks within the behavior is designated the "code block to select." If you apply the server behavior and then select the behavior in the Server Behaviors panel, in the Document window Dreamweaver automatically selects the designated block. By default, Dreamweaver selects the first code block that is not above the html tag. If all the code blocks are above the html tag, then Dreamweaver selects the first one. Advanced users can specify which code block is the selected one.
Repeat steps 1 to 4 for each code block in your server behavior.
If you have two or more code blocks with the same insert location, you can change their positions relative to each other by clicking the up and down arrows.
Do one of the following:
- If you did not define any designer-supplied parameters in your code, click OK.
  Dreamweaver creates the server behavior with no dialog box. The new server behavior appears in the Plus (+) menu of the Server Behaviors panel.
- If you defined designer-supplied parameters in your code, Dreamweaver prompts you to configure a dialog box for the server behavior before creating it.
  For more information, see Creating a dialog box for a custom server behavior.

Setting the New Server Behavior dialog box options

2009-01-21T10:16:00.000-08:00

This dialog box lets you choose the document type you are developing the server behavior for, and name the new server behavior.

To complete the New Server Behavior dialog box:

Select a document type from the pop-up menu.

Enter a name for the server behavior.
If you want your new server behavior to be based on a server behavior that ships with Dreamweaver, select the Copy Existing Server Behavior option and select the Dreamweaver server behavior in the Behavior To Copy pop-up menu.
Click OK.
The New Server Behavior Builder appears.

Editing and modifying server behaviors

2009-01-21T10:15:00.000-08:00

You can edit any server behavior created with the Server Behavior Builder, including server behaviors you download from the Macromedia Exchange website, and other third-party developers.

If you apply a server behavior to a page and then edit the behavior in Dreamweaver, instances of the old behavior will no longer appear in the Server Behaviors panel. The Server Behaviors panel searches the page for code that matches the code of known server behaviors. If the code of a server behavior known to the panel changes, the panel will no longer recognize earlier versions of the behavior on that page.

If you want both the old and new versions of the behavior to appear in the panel:

Click the Plus (+) button on the Server Behaviors panel (Window > Server Behaviors), select New Server Behavior, and create a copy of the old server behavior.

To edit the code of a server behavior created with the Server Behavior Builder:

In the Server Behaviors panel (Window > Server Behaviors), click the Plus (+) button and select Edit Server Behaviors from the pop-up menu.
The Edit Server Behaviors dialog box appears, displaying all the behaviors for the current server technology.
Select the server behavior and click Edit.
The Server Behavior Builder dialog box appears.
Select the appropriate code block and modify the code to be inserted in pages.
(Optional) You can change or add parameter markers to the code.
For instructions, see Creating a dialog box for a custom server behavior.
(Optional) If you want, change where the code block is inserted in the page’s HTML code by choosing another option in the Insert Code pop-up menu.
For instructions, see Positioning code blocks.
If the modified code does not contain any designer-supplied parameters, click OK.
Dreamweaver regenerates the server behavior without a dialog box. The new server behavior appears in the Plus (+) pop-up menu of the Server Behaviors panel.
If the modified code does contain designer-supplied parameters, click Next.
Dreamweaver asks you whether you want to create a new dialog box, overwriting the old one. Make your changes and click OK.

Dreamweaver saves all changes in the server behavior’s EDML file.

Creating a dialog box for a custom server behavior

2009-01-21T10:14:00.000-08:00

Server behaviors often require that the page designer supply a parameter value. This value must be inserted before the server behavior’s code is inserted into the page. To do this, you can create a dialog box that prompts the person implementing the server behavior for a parameter value.

You create the dialog box by defining the designer-supplied parameters in the code. After defining all the parameters, you can generate a dialog box for the server behavior.

NOTE

A parameter is added to your code block without your intervention if you specify that your code should be inserted relative to a specific tag chosen by the page designer (that is, you chose Relative to a Specific Tag in the Insert Code pop-up menu). The parameter adds a tag menu to the behavior’s dialog box to let the page designer select a tag.

To create a parameter in the server behavior’s code:

Enter a parameter marker at the point in the code where you want to insert the supplied parameter value. The syntax for the parameter is as follows:
```
@@parameterName@@
```

For example, if the server behavior contains the following code block:

To let the page designer supply the value of Form_Object_Name, enclose the string in parameter markers (@@):

You can also highlight the string and click the Insert Parameter In Code Block button. Enter a parameter name and click OK. Dream weaver replaces every instance of the highlighted string with the specified parameter name enclosed in parameter markers.

Dreamweaver uses the strings you enclose in parameter markers to label the controls in the dialog box it generates (see the following procedure). In the previous example, Dreamweaver creates a dialog box with the following label:

NOTE

Parameter names in the server behavior code cannot have any spaces. Therefore, the dialog box labels cannot have any spaces. If you want to include spaces in the label, you can edit the generated HTML file.

To create a dialog box for a server behavior:

In the Server Behavior Builder, click Next.
A dialog box appears listing all of the designer-supplied parameters you defined in your code.
(Optional) You can change the display order of the dialog box controls by selecting a parameter and clicking the up and down arrows.
(Optional) If you want, change a parameter’s control by selecting the parameter and choosing another control in the Display As column.
Click OK.
Dreamweaver generates a dialog box with a labeled control for each designer-supplied parameter you defined.

To view the dialog box:

Click the Plus (+) button in the Server Behaviors panel (Window > Server Behaviors), and select your server behavior from the pop-up menu.

To edit the dialog box of a server behavior you created:

In the Server Behaviors panel (Window > Server Behaviors), click the Plus (+) button and select Edit Server Behaviors from the pop-up menu.
Select your server behavior from the list, and click Open.
The Server Behavior Builder appears with your server behavior.
Click Next.
A dialog box appears listing all the designer-supplied parameters you defined in your code.
(Optional) You can change the display order of the dialog box controls by selecting a parameter and clicking the up and down arrows.
(Optional) If you want, change a parameter’s control by selecting the parameter and choosing another control in the Display As column.
Click OK.

Positioning code blocks

2009-01-21T10:12:00.000-08:00

When you create code blocks using the Server Behavior Builder (see Using the Server Behavior Builder for more information), you must specify where to insert them in the page’s HTML code. The Insert Code and Relative Position pop-up menus let you choose where to insert the code block in the document, and then specify a position relative to another tag in the page.

To learn more about the code block positioning options and how they affect your custom server behavior, see Code block positioning within web pages.

To position a code block (general instructions):

Using the Server Behavior Builder, write a code block according to the section Using the Server Behavior Builder.
In the Server Behavior Builder dialog box, select a position in which to insert the code block from the Insert Code pop-up menu.
In the Server Behavior Builder dialog box, select a position relative to that which you selected in the Insert Code pop-up menu.
If you have completed the authoring of the code block, click OK.
The server behavior is listed in the Server Behaviors panel (Window > Server Behavior), and can be viewed by clicking the click the Plus (+) button.
Test the server behavior and ensure that it functions properly.
See Testing server behaviors for more information.

To position a code block relative to another tag on the page:

In the Insert Code pop-up menu, select Relative To a Specific Tag.
In the Tag text box, enter the tag or select one from the pop-up menu.
If you enter a tag, don’t include the angled brackets (< >).
Specify a location relative to the tag by choosing an option in the Relative Position pop-up menu.
You can insert your code block just before or just after the opening or closing tags. You can also replace the tag with the code, insert the code as the value of an attribute of the tag (a box appears to let you select the attribute), or insert the code inside the opening tag.

To position a code block relative to a tag selected by the page designer:

In the Insert Code pop-up menu, select Relative To the Selection.
Specify a location relative to the selection by choosing an option in the Relative Position pop-up menu.
You can insert your code block just before or just after the selection. You can also replace the selection with your code block, or you can wrap the code block around the selection.

If you want to wrap the code block around a selection, the selection must consist of an opening and closing tag with nothing in between, as follows:
The opening tag piece of the code block is inserted before the selection’s opening tag and the closing tag piece of the code block is inserted after the selection’s closing tag.

Using parameters in server behaviors

2009-01-21T10:11:00.000-08:00

You can include parameters in a server behavior’s code (see Parameters in server behaviors for more information), and let the page designer supply the necessary parameter values before inserting the server behavior’s code into the page. To let the page designer supply parameter values, enter parameter markers within the code as shown:

@@parameterName@@

The ASP server behavior example below contains the parameter formParam, which requires the person inserting the behavior to supply the name of a form object:

<% Session("lang_pref") = Request.Form("formParam"); %>

To create a parameter that lets the user supply the necessary value:

Enclose the formParam string in parameter markers:

<% Session("lang_pref") = Request.Form("@@formParam@@"); %>

Create a dialog box that prompts the designer to supply the name of the form object.
For more information, see Creating a dialog box for a custom server behavior.

Using the Server Behavior Builder

2009-01-21T10:10:00.000-08:00

The Server Behavior Builder lets you add the code block or blocks that the behavior inserts into a page.

To write server behavior code blocks:

In the Server Behaviors panel (Window > Server Behaviors), click the Plus (+) button and select New Server Behavior from the pop-up menu.
The New Server Behavior dialog box appears.
From the Document Type pop-up menu, select the document type that you are developing the server behavior for.
In the Name text box, enter a name for the server behavior.
If you want to copy an existing server behavior to add to the behavior you are creating, select the Copy Existing Server Behavior checkbox.
When this checkbox is selected, a list of available server behaviors is displayed in the Behavior to Copy pop-up menu.
Click OK.
The Server Behavior Builder dialog box is displayed.
To add a new code block, click the Plus (+) button.
The Create a New Code Block dialog box is displayed.
Enter a name for the code block you want to create and click OK.
The name you entered in the dialog box appears in the Server Behavior Builder, with the appropriate scripting tags visible in the Code block text box.
In the Code Block text box, enter the code necessary to implement the server behavior.
When entering code in the Code Block text box:
- You can insert only a single tag or code block for each named code block (for example, myBehavior_block1, myBehavior_block2, myBehavior_blockn, etc.). If you need to enter multiple tags or code blocks, you must create an individual code block for each using the Server Behavior Builder.
- To include runtime parameters in a code block:
1. Place the insertion point in the code block where you’d like to insert the parameter.
2. Click the Insert Parameters in Code Block button.
  The Insert Parameters in Code Block dialog box appears.
3. Enter a name for the parameter in the Parameter Name text box.
4. Click OK.
  The parameter name is inserted in the code block.
- Repeat steps 6 through 8 for each new code block you want to create.
In the Parameter Name pop-up menu, enter a name for the parameters, and click OK.
The parameter is inserted into the code block at the location where you placed the insertion point prior to defining the parameter.
Select an option from the Insert Code pop-up menu specifying the location in which to embed the code blocks.
For more information see Positioning code blocks.
You can specify additional information about the server you are creating by using the Advanced options panel.
Click the Advanced button to display more options.
If you need to create more code blocks, repeat steps 7 through 13 as needed.
If the server behavior requires that parameters be supplied to it, you will need to create a dialog box that accepts parameters from the person applying the behavior.
To create a dialog box that accepts user input parameters, see Creating a dialog box for a custom server behavior.
After you have performed the above steps as required by the server behavior you are creating, Click OK.
Once you create a server behavior, it is listed in the Server Behaviors panel. Test the server behavior and ensure that it functions properly.

Installing third-party server behaviors

2009-01-21T10:05:00.000-08:00

You can download and install server behaviors created by independent developers from the Macromedia Exchange website.

To access Macromedia Exchange:

In Dreamweaver select Help > Dreamweaver Exchange.
Your browser opens the Macromedia Exchange for Dreamweaver web page.
Log on to the Exchange using your Macromedia ID, or, if you have not yet created a Macromedia Exchange ID for yourself, follow the instructions to open a Macromedia account.

NOTE

You can also access the Macromedia Exchange from the Server Behaviors panel (Window > Behaviors) by clicking the Plus (+) button and selecting Get More Server Behaviors.

To install a server behavior or other extension in Dreamweaver:

Start the Extension Manager by selecting Commands > Manage Extensions.
Select File > Install Package in the Extension Manager.
For more information, see Using the Extension Manager.

About custom server behaviors

2009-01-21T10:02:00.000-08:00

Before creating your own server behaviors, you should check the Macromedia Exchange website to see if another party has already created a server behavior that supplies the functionality you’d like to add to your website. Often, a third-party developer has created and tested a server behavior that will address your needs.

The server behaviors and other extensions available through the Macro media Exchange website allow you to easily add new features to Dream weaver. Each server behavior includes a short description, user reviews, and a discussion group where you can post questions and get support for the server behaviors you download.

If you are going to create your own server behavior, you should be familiar with the web programming language used by your website. This chapter provides guidelines specific to creating server behaviors using Dream weaver. It does not instruct you in programming languages or server behavior testing.

This section covers the following conceptual topics:

Testing server behaviors

2009-01-21T10:01:00.002-08:00

The Macromedia Exchange recommends performing the following tests on each server behavior you create:

Apply the behavior from the Server Behaviors panel. If it has a dialog box, enter valid data in each field and click OK. Verify that no error occurs when the behavior is applied. Verify that the runtime code for the server behavior appears in the Code inspector.
Apply the server behavior again and enter invalid data in each field of the dialog box. Try leaving the field blank, using large or negative numbers, using invalid characters (such as /, ?, :, *, and so on), and using letters in numeric fields. You can write form validation routines to handle invalid data (validation routines involve hand-coding, which is beyond the scope of this book).

After successfully applying your server behavior to the page, verify the following:

Check the Server Behaviors panel to make sure the name of the server behavior appears in the list of behaviors added to the page.
If applicable, verify that server-side script icons show up on the page. The generic server-side script icons are gold shields. To see the icons, enable Invisible Elements (View > Visual Aids > Invisible Elements).
In Code view, (View > Code) verify that no invalid code is generated.

In addition, if your server behavior inserts code in the document establishing a connection to a database, create a test database to test the code inserted in the document. Verify the connection by defining queries that produce different sets of data, and different sizes of data sets.

Finally, upload the page to the server and open it in a browser. View the page’s HTML source code and verify that no invalid HTML has been generated by the server-side scripts.

Coding guidelines

2009-01-21T10:01:00.001-08:00

In general, your server behavior’s code should be compact and robust. Web application developers are very sensitive to the code added to their pages. Follow generally accepted coding practices for the document type’s language (ColdFusion, ASP.NET, JavaScript, VBScript, PHP, Visual Basic or Java). When writing comments, consider the different technical audiences that might need to understand the code, such as web and interaction designers, or other web application developers. Include comments that accurately describe the purpose of the code, and any special instructions for including it within a page.

The following is a list of coding guidelines to keep in mind when creating server behaviors:

Error checking is an important requirement. The server behavior’s code should handle error cases gracefully. Try to foresee every possibility. For example, what if a parameter request fails? What if no records are returned from a query?

Unique names help to ensure that your code is clearly identifiable and avoids name collisions with existing code. For example, if the page contains a function called hideLayer() and a global variable called ERROR_STRING, and your server behavior inserts code that uses those names too, the server behavior may conflict with the existing code.

Code prefixes allow you to identify your own runtime functions and global variables in a page. One convention is to use your initials. Never use the MM_ prefix, as it is reserved for Macromedia use only. Macromedia precedes all functions and global variables with the prefix MM_ to prevent them from conflicting with any code that you write.

var MM_ERROR_STRING = "...";
function MM_hideLayer() {

Avoid similar code blocks so that the code you write doesn’t resemble too closely the code in other blocks. If a code block looks too much like another code block on the page, the Server Behaviors panel might mistakenly identify the first code block as an instance of the second code block (or conversely). A simple solution is to add a comment to a code block to make it more unique.

Repeating code blocks

2009-01-21T09:59:00.002-08:00

When creating server behaviors, you can use looping constructs to repeat a code block a specified number of times. The loop syntax is:

<@ loop (@@param1@@,@@param2@@,@@param3@@,@@param_n@@) @>
  code block
<@ endloop @>

The loop directive accepts a comma-separated list of parameter arrays as arguments. In this case, parameter array arguments allow a user to supply multiple values for a single parameter. The repeating text will be duplicated n times, where n is the length of the parameter array arguments. If more than one parameter array argument is specified, all the arrays must have the same length. On the ith evaluation of the loop, the ith elements of the parameter arrays replace the associated parameter instances in the code block. For more information, see Using the loop directive’s _length and _index variables.

When you later create a dialog box for the server behavior (see Creating a dialog box for a custom server behavior), you can add a control to the dialog box that allows the page designer to create parameter arrays. Dreamweaver includes a simple array control that you can use to create dialog boxes. This control, called Text Field Comma Separated List, is available through the Server Behavior Builder. To create user interface elements of greater complexity, see the API documentation to create a dialog box with a control to create arrays (a grid control, for example).

Loop directives cannot be nested, but conditional directives (see Positioning code blocks) can be nested within a loop directive.

The following example shows how such repeating code blocks can be used to create server behaviors (the example is a ColdFusion behavior used to access a stored procedure):

  datasource=#MM_connection_DSN#
  username=#MM_connection_USERNAME#
  password=#MM_connection_PASSWORD#>
  cfsqltype="CF_SQL_INTEGER">
  cfsqltype="CF_SQL_VARCHAR">

In this example, the CFSTOREDPROC tag can include zero or more CFPROCPARAM tags. However, without support for the loop directive, there is no way to include the CFPROCPARAM tags within the inserted CFSTOREDPROC tag. If this were to be created as a server behavior without the use of the loop directive, you would need to divide this example into two participants: a main CFSTOREDPROC tag, and a CFPROCPARAM tag whose participant type is multiple.

Using the loop directive, the same procedure can be written as follows:

datasource=#MM_@@conn@@_DSN#
username=#MM_@@conn@@_USERNAME#
password=#MM_@@conn@@_PASSWORD#>
<@ loop (@@paramName@@,@@value@@,@@type@@) @>
    dbvarname="@@paramName@@"
  value="@@value@@"
  cfsqltype="@@type@@">
<@ endloop @>

In the previous example, and in the case of conditional code blocks as well, newlines after @> are ignored.

If the user entered the following parameter values in the Server Behavior Builder dialog box:

procedure = "proc1"
conn = "connection1"
paramName = ["@CategoryId", "@Year", "@ISBN"]
value = ["#Form.CategoryId#", "#Form.Year#", "#Form.ISBN#"]
type = ["CF_SQL_INTEGER", "CF_SQL_INTEGER", "CF_SQL_VARCHAR"]

The server behavior would insert the following runtime code in the page:

datasource=#MM_connection1_DSN#
username=#MM_connection1_USERNAME#
password=#MM_connection1_PASSWORD#>

  cfsqltype="CF_SQL_INTEGER">
  cfsqltype="CF_SQL_INTEGER">
  cfsqltype="CF_SQL_VARCHAR">

NOTE  Parameter arrays cannot be used outside of a loop except as part of a conditional directive expression.

Using the loop directive’s _length and _index variables

2009-01-21T09:59:00.001-08:00

The loop directive includes two built-in variables that you can use for embedded if conditions. The variables are: _length and _index. The _length variable evaluates to the length of the arrays processed by the loop directive, while the _index variable evaluates to the current index of the 'loop' directive. To ensure that the variables are only recognized as directives, and not as actual parameters to be passed into the loop, do not enclose either variable in @@’s.

An example of using built-in variables is to apply them to the import attribute of the page directive. The import attribute requires comma separation of packages. If the loop directive extends around the entire import attribute, you would only output the attribute name import= on the first iteration of the loop--this includes the closing double quote (")--and not output a comma on the last iteration of the loop. Using the built-in variable, you can express this as follows:

<@loop (@@Import@@)@>
<@ if(_index == 0)@>import="
<@endif@>@@Import@@<@if (_index == _length-1)@>"<@else@>,
<@ endif @>
<@endloop@>

Effectively using conditional expressions

2009-01-21T09:58:00.001-08:00

When using if, else, and elseif directives within the insertText XML tag, the participant text is preprocessed to resolve the if directives and to determine which text to include in the result. The if and elseif directives take the expression as an argument. The condition expression is the same as that for JavaScript condition expressions, and can also contain server behavior parameters. Directives such as this allow you to choose between alternative code blocks based on the values of, or relationships between, server behavior parameters.

For example, the following JSP code comes from a Dreamweaver server behavior that uses the conditional code block:

@@rsName@@.close();

@@rsName@@_hasData = @@rsName@@.next();

If the server behavior uses a normal recordset, the placeholder is replaced with:

@@rsName@@ = Statement@@rsName@@.executeQuery();

If the server behavior uses a recordset from a callable object, it uses the following code instead.

@@callableName@@.execute();


@@rsName@@ = @@callableName@@.getResultSet();

If the server behavior is added for a callable object, the user would enter a value for the @@callableName@@ parameter in the server behavior’s Parameter dialog box. Otherwise, the @@callableName@@ parameter would be empty. Thus, you can rewrite the previous insert text using @@callableName@@ as the if argument. In this example, if the @@callableName@@ parameter is supplied with a value, and first conditional code block (containing the getResultSet() method) is selected:

@@rsName@@.close();
<@ if (@@callableName@@ != '') @>
@@callableName@@.execute();
@@rsName@@ = @@callableName@@.getResultSet();@ else @>
@@rsName@@ = Statement@@rsName@@.executeQuery();
<@ endif @>
@@rsName@@_hasData = @@rsName@@.next();

Making code blocks conditional

2009-01-21T09:57:00.000-08:00

Dreamweaver lets you develop code blocks that incorporate control statements that execute conditionally. The Server Behavior Builder uses if, elseif, and else statements, and may also contain server behavior parameters. This enables you to insert alternate text blocks based on the values of OR relationships among server behavior parameters. The if, elseif, and else

statements appear as shown below. Note that square brackets ([ ]) denote optional code, and the asterisk (*) denotes zero or more instances:

<@ if (expression1) @>
  conditional text1
[<@ elseif (expression2) @>
  conditional text2]*
[<@ else @>
  conditional text3]
<@ endif @>

Condition expressions can be any JavaScript expression that can be evaluated using the JavaScript eval() function, and may include a server behavior parameter marked by @@'s. (The @@'s are necessary to distinguish the parameter from JavaScript variables and keywords.)

You can nest any number of conditionals or a loop directive (see Repeating code blocks) within a conditional directive. For example, you can specify that if an expression is true to execute a loop.

NOTE

New lines after each "@>" are ignored.

This section covers the following topics:

Effectively using conditional expressions
Repeating code blocks

Parameters in server behaviors

2009-01-21T09:56:00.000-08:00

You can include parameters in a server behavior’s code, and let the page designer supply the necessary parameter values before inserting the server behavior’s code into the page. To let the page designer supply parameter values, enter parameter markers within the code as shown:

@@parameterName@@

The example ASP server behavior below contains the parameter formParam, which requires the person inserting the behavior to supply the name of a form object:

<% Session("lang_pref") = Request.Form("formParam"); %>

To create a parameter that lets the user supply the necessary value:

Enclose the formParam string in parameter markers:

<% Session("lang_pref") = Request.Form("@@formParam@@"); %>

Create a dialog box that prompts the designer to supply the name of the form object. For more information, see Creating a dialog box for a custom server behavior.

About code blocks

2009-01-21T09:55:00.000-08:00

The code blocks you create in the Server Behavior Builder are encapsulated in a server behavior that appears in the Server Behaviors panel. The code can be any valid runtime code for the specified server model. For example, if you choose ColdFusion as the document type for your custom server behavior, then the code you write must be valid ColdFusion code that runs on a ColdFusion application server.

Code blocks

You can create the code blocks either directly within the Server Behavior Builder, or you can copy and paste the code from other sources. Each code block you create in the Server Behavior Builder must be a single tag or script block. If you need to insert multiple tag blocks, split them into separate code blocks.

For more information, see Using the Server Behavior Builder

Runtime Parameters

You can include parameters in your runtime code and let the page designer supply the parameter values. To do so, enter parameter markers in the code, as follows:

@@parameterName@@

For more information, see Using parameters in server behaviors.

Conditions and repeating elements in code blocks

If you want the code block, or a portion of a code block, to be executed only if a certain condition or conditions apply, use the following syntax:

<@ if (expression1) @>
 code block1
[<@ elseif (expression2) @>
 code block2]*
[<@ else @>
 code block3]
<@ endif @>

The square brackets ([ ]) denote optional code and the asterisk (*) denotes zero or more instances. The condition expression is any valid JavaScript condition expression, and may contain server behavior parameters.

If you want the code block, or a portion of a code block, to be repeated a number of times, use the following syntax:

<@ loop (@@param1@@,@@param2@@) @>
 code block
<@ endloop @>

The loop directive takes a comma-separated list of parameter arrays as arguments. The repeating text will be duplicated n times, where n is the length of the parameter array arguments. If more than one parameter array argument is specified, all the arrays must have the same length. On the ith evaluation of the loop, the ith elements of the parameter arrays replace the associated parameter instances in the code block.

For general information on coding, see Coding guidelines.

Code block positioning within web pages

When you create code blocks using the Server Behavior Builder (see Using the Server Behavior Builder for more information), you must specify where to insert them in the page’s HTML code. You do this using the Server Behavior Builder dialog box’s Insert Code and Relative Position pop-up menus, which let you select where to insert the code block within the document, and then specify a position relative to another tag in the page.

For example, if you insert a code block above the opening tag, you must then specify the code blocks position relative to other tags, scripts, and server behaviors in that section of the page’s HTML code. Typical examples include positioning a behavior either before or after any recordset queries that might also exist in the page code above the opening tag.

When you select a positioning option from the Insert Code pop-up menu, the options available in the Relative Position pop-up menu change to provide relevant options for that part of the page. For example, if you select Above the Tag in the Insert Code pop-up menu, then the positioning options available in the Relative Position pop-up menu reflect choices relevant for that part of the page.

The code block insert options, and the relative positioning options available for each, are shown in the table below.

Insert Code options	Relative position options
Above the Tag	At the beginning of the file Just before the recordsets Just after the recordsets Just above the tag Custom position
Below the Tag	Before the end of the file Before the recordset close After the recordset close After the tag Custom position
Relative to a Specific Tag	Select a tag from the Tag pop-up menu, and then choose from the tag positioning options.
Relative to the Selection	Before the selection After the selection Replace the selection Wrap the selection

If you want to specify a custom position, you must assign a weight to the code block. Use the Custom Position option when you need to insert more than one code block in a particular order. For example, if you want to insert an ordered series of three code blocks after the code blocks that open record sets, you would enter a weight of 60 for the first block, 65 for the second, and 70 for the third.

By default, Dreamweaver assigns a weight of 50 to all recordset-opening code blocks inserted above the tag. If the weight of two or more blocks match, Dreamweaver randomly sets the order among the blocks.

Server behaviors

2009-01-21T09:53:00.000-08:00

If you are a developer proficient in Macromedia ColdFusion, ASP.NET, JavaScript, VBScript, PHP, or Java, you can write your own server behaviors. The steps to create a server behavior include the following tasks:

Writing one or more code blocks that perform the required action.
For information on creating server behaviors with the Dreamweaver Server Behavior Builder see Using the Server Behavior Builder. For information on the syntax supported by Dreamweaver server behaviors, see Using parameters in server behaviors.
Specifying where the code block should be inserted within the page’s HTML code.
For information on positioning code blocks within a page see Positioning code blocks.
If the server behavior requires that a value be specified for a parameter, creating a dialog box that prompts the web developer applying the behavior to supply an appropriate value.
For information on supplying parameter values to a server behavior using a dialog box see Creating a dialog box for a custom server behavior.
Testing the server behavior before making it available to others.
For guidelines on testing server behaviors see Testing server behaviors.

Creating Forms

2009-01-21T09:50:00.002-08:00

You can use Macromedia Dreamweaver 8 to create forms with text fields, password fields, radio buttons, checkboxes, pop-up menus, clickable buttons, and other form objects. Dreamweaver can also write code that validates the information a visitor provides. For example, you can check that an e-mail address a user enters contains an "@" symbol, or that a required text field contains a value.

This chapter contains the following sections:

About forms

Creating HTML forms

Inserting HTML form objects

Inserting dynamic HTML form objects

Validating HTML form data

Attaching JavaScript behaviors to HTML form objects

Attaching custom scripts to HTML form buttons

Creating accessible HTML forms

Reference

Dreamweaver Help and Guide

Resources

Displaying Database Records

About displaying database records

Server behaviors and formatting elements

Applying typographic and page layout elements to dynamic data

Navigating database recordset results

Custom recordset navigation bars

Navigation bar design tasks

Displaying and hiding regions based on recordset results

Displaying multiple recordset results

Record counters

Simple record counters

Custom record counters

Using predefined data formats

To apply data formats to dynamic content:

Customizing existing data formats

To customize a data format:

Creating new data formats

You can create new data formats to suit any type of dynamic data you want to display.

To create a new data format:

Creating recordset navigation links

Recordset navigation links let users move from one record to the next, or from one set of records to the next. For example, after designing a page to display five records at a time, you might want to add links such as Next or Previous that let users display the five next or previous records.

Creating a navigation bar using the Recordset Navigation Bar server behavior

To create the recordset navigation bar with the server object:

Creating a custom recordset navigation bar

To assign server behaviors to recordset navigation links:

Showing and hiding regions based on recordset results

To show a region only when it’s needed:

Displaying multiple recordset results

To create a repeated region:

Creating a table with a Repeat Region server behavior

To create a dynamic table:

Creating a record counter

Creating a record counter using the Recordset Navigation Status object

To use the Recordset Navigation Status server object:

Creating custom record counters

To create a custom record counter:

Displaying XML Data in Web Pages

About using XML and XSL with web pages

About server-side XSL transformations

About client-side XSL transformations

About XML data and repeating elements

About previewing XML data

Previewing pages for server-side transformations

Previewing pages for client-side transformations

Previewing entire XSLT pages and XSLT fragments

Performing XSL transformations on the server

Performing XSL transformations on the server

Workflow for performing server-side XSL transformations

Creating XSLT pages

To create an XSLT page:

Converting HTML pages to XSLT pages

To convert an existing HTML page to an XSLT page:

Attaching XML data sources

To attach an XML data source:

Displaying XML data in XSLT pages

To display XML data:

Displaying repeating XML elements

To display repeating XML elements:

Editing a Repeat Region XSLT object

To edit a Repeat Region XSLT object:

Inserting XSLT fragments in dynamic pages

To insert an XSLT fragment in a web page:

Deleting XSLT fragments from dynamic pages

To delete an XSLT fragment from a dynamic page:

Editing XSL Transformation server behaviors

To edit an XSL Transformation server behavior:

Using parameters with XSL transformations

To add an XSLT parameter to an XSL transformation:

To edit an XSLT parameter:

To delete an XSLT parameter:

Creating conditional XSLT regions

To create a conditional XSLT region:

Editing a Conditional Region XSLT object

To edit a Conditional Region XSLT object:

Inserting XSL comments

To add XSL comment tags to a document:

To wrap a selection in XSL comment tags:

Performing XSL transformations on the client