Your testing server can be your local computer, a web server on the Internet, or a web server on your local network. The pivotal criterion is that the server must have the ability to process the type of dynamic pages you develop. To properly configure your website to use a testing server to preview web pages in a browser or in Live Data view, you must define your testing server to use a specific server technology, you must specify a local path to your website home directory, and you must specify a URL to your website.
To define your testing server, follow these steps:
Choose Sites ® Edit Sites to open the Edit Sites dialog box, which is shown in Figure 19.4.
Figure 19.4: The Edit Sites dialog box
Select your website, and then click the Edit button to open the Site Definition dialog box.
Click the Advanced tab, and select Testing Server from the Category list.
In the Testing Server section, be certain your website script language is properly defined in the Server Model drop-down list box.
In the Access drop-down list box, choose a method for accessing your testing server. If your server is hosted by an ISP, you'll want to configure FTP (File Transfer Protocol) as your testing server access method. If you have local network access to your testing server, choose Local/ Network.
In the URL Prefix text box, enter the URL of your testing server. The URL is the web address Dreamweaver MX will use to preview the HTML results of your script file. For example, Figure 19.5 shows the testing server configuration for our ASP (Active Server Pages) application website. Notice we have specified ASP VBScript as our server model, set the access to our testing server through our local network, entered the local file path to the site directory, and inserted the URL to get to our ASP application website through a web browser.
Figure 19.5: The ASP website testing server configuration
Standard practice for all web developers throughout the development cycle is to preview their pages on the web server in a browser. Dreamweaver MX speeds up this process by allowing you to instantly preview any page you create with the Preview In Browser command. To do so, choose File â Preview in Browser or press the F12 key. Dreamweaver MX creates a temporary version of your web page on your testing server, opens your choice of web browsers (typically Internet Explorer or Netscape Navigator), and displays the temporary file.
Dreamweaver MX creates only a temporary version of the current file on the web server. Dreamweaver MX does not create temporary files for related or included files that the current file may reference. Therefore, you might need to upload a related or an included file. To do so, choose Site â Site Files to open the Site panel, select the appropriate files, and click the blue arrow.
As we mentioned, Live Data view displays the HTML results of the current script file within Dream- weaver MX. This may sound inconsequential, but it has a dramatic effect on the way most coders and designers develop. In the past, web developers scripted a bit of code, saved the file, jumped out to a web browser to preview the result, and then jumped back to the code. Live Data view allows you to visually design and modify your script page with real dynamic data all from within Dreamweaver MX. To switch from Design to Live Data view and back again, choose View â Live Data.
What's more, Macromedia realizes that most dynamic pages require that some parameter be passed to render the proper result. Therefore, Macromedia accounts for these requirements in Live Data view. You can actually set Dreamweaver MX to create and pass any type of variable or value to your page. To demonstrate, let's create a URL variable to pass to the Live Data view of an ASP page. Follow these steps:
Create or open an ASP website in Dreamweaver MX.
Set the testing server as we've described earlier in this chapter.
Open a new VBScript ASP file and name it LiveDataView.asp.
In the body of the document, you need to insert labels and output statements to print a query string (or URL) variable named varQueryString and a form variable named varForm to the browser window.
Type varQueryString: in your script page.
Choose Insert ® ASP Objects ® Output.
Choose Trimmed QueryString Element from the ASP Objects menu. Dreamweaver MX inserts the output and the Trimmed QueryString Element request code line in your ASP script page.
Position your cursor between the quotes of the Trimmed QueryString Element request code and type varQueryString.
Now duplicate the process to insert an output statement that prints a form variable named varForm to the browser window.
Insert a <BR> statement after the varQueryString output statement to separate the variables with a line break.
Enter varForm:, then choose Insert ® ASP Objects ® Output.
Choose Trimmed Form Element from the ASP Objects menu. Dreamweaver MX inserts the output and the Trimmed Form Element request code line in your ASP script page.
Position your cursor between the quotes of the Trimmed Form Element request code and type varForm.
Figure 19.6 shows the completed output line to display the Trimmed QueryString Element named varQueryString and the Trimmed Form Element named varForm in the browser window.
Figure 19.6: The varQuery- String and varForm output line
Now let's set Dreamweaver MX to pass the varQueryString variable and value to display the value in Live Data view. Follow these steps:
Choose View ® Live Data Settings or click the Settings button on the toolbar of your Dream- weaver MX script file to open the Live Data Settings dialog box, which is shown in Figure 19.7.
Figure 19.7: The Data View Settings dialog box
In the Name column of the URL Request list, enter varQueryString.
In the Value column of the URL Request list, enter This is the varQueryString value.
In the Method drop-down list box, select GET.
Click OK to close the dialog box, and choose View ® Live Data to switch your Dreamweaver MX ASP script file to Live Data view.
As you can see in Figure 19.8, our script page displays the value of the QueryString variable varQueryString that Dreamweaver passed.
Figure 19.8: The LiveData view of varQueryString
Now, let's change the Live Data view settings to pass the form variable varForm instead of the QueryString variable varQueryString. Follow these steps:
Open the Live Data Settings dialog box, which is shown in Figure 19.9.
Figure 19.9: The varForm Live Data Settings dialog box
Click the minus sign (–) button to remove the varQueryString variable from the URL Request list.
In the Name column, enter varForm, and in the Value column, enter This is the varForm value.
In the Method drop-down list box, change the method from GET to POST.
Click OK to close the dialog box, and choose View ® Refresh Design to refresh the Live Data view.
As you can see in Figure 19.10, the Live Data view now shows the value of the passed form variable varForm.
Figure 19.10: The Live Data view of varForm
In addition to QueryString and Form variables, you can also use Live Data view to initialize application, session, and cookie variables before Dreamweaver MX previews your script file. As we've mentioned in previous chapters, an application variable is available to all pages running in your web application. A session variable is tied to the user and is available to every page the user accesses. A cookie is a text file written to the user's computer and is available to every page on your website. To set Live Data view to initialize an application, a session, and a cookie variable before it previews your ASP page, follow these steps:
Open the Live Data Settings dialog box.
Place your cursor in the Initialization Script text area.
Enter the following lines to create a varApplication application variable, a varSession session variable, and a varCookie cookie:
<% application("varApplication") = "This is the varApplication value" session("varSession") = "This is the varSession value" response.cookies("varCookies") = "This the varCookie value" %>
Click OK to close the Live Data Settings dialog box.
Now alter the LiveDataView.asp script file to display the application, session, and cookie variables.
Add the following lines to your ASP script file.
varApplication: <%= application("varApplication") %><br> varSession: <%= session("varSession") %><br> varCookies: <%= request.cookies("varCookies") %><br>
Choose View®Refresh Design to refresh Live Data view.
As you can see in Figure 19.11, Dreamweaver MX runs the initialization code to create the application, session, and cookie variables and values and previews them in Live Data view.
Figure 19.11: Live Data View of application, session, and cookie variables
Live Data view is a great tool, but it does behave in a unique way that is different from previewing a script page in a browser. You should know about the following behaviors:
Although we've already covered this, for the sake of thoroughness, let's restate. Live Data view uses the testing server to generate the HTML results of your script page and then displays the results in your Dreamweaver window. Therefore, your Dreamweaver MX website testing server must be configured correctly and accessible through a URL.
While displaying a Live Data view, you can alter the layout using the page-design tools. You can add, modify, or delete dynamic content; add, modify, or delete Server Behaviors; and edit the code in your script page.
Depending on the way you've configured Dreamweaver MX, Live Data view might not automatically refresh its view once you make changes to your script page. To refresh the Live Data view, choose View ® Refresh Design or click the Refresh icon (a circle-arrow) on the toolbar of your script page. Likewise, to set Live Data view to automatically refresh, select the Auto Refresh check box in the toolbar of your script page.
Saving your file turns off Live Data view.
Links do not function in Live Data view.
To properly render the active script page, related or included files must be available to the testing web server. To upload a related or an included file, choose Site ® Site Files to open the Site panel, select the appropriate files, and click the blue arrow.
Throughout the chapter, we mention that the Recordset Server Behavior is universal to all Dreamweaver MX– supported languages. That is true with one exception—ASP.NET uses a DataSet in place of a recordset. Although dramatic differences separate the definition and functionality of a recordset and a DataSet, the Dreamweaver MX interfaces to create a recordset or a DataSet are virtually the same. Therefore, for this chapter only, we'll refer to both as a recordset.