Server Behaviors

Team-Fly    

Macromedia® DreamWeaver® MX Unleashed
By Matthew Pizzi, Zak Ruvalcaba
Table of Contents
Appendix B.  Server Behavior Builder


The built-in server behaviors are powerful because they allow nonprogrammers, or those with only a limited knowledge of server-side programming, to perform common functions such as displaying database records. They can be used by Web designers to visually design a page to produce simple Web applications. If they need to modify the page after design maybe to reorder database columns or to add in more data there is no need to hunt through and modify code; the server behavior can be easily changed.

Server behaviors are also useful to experienced programmers. So much of Web application coding is the repetition of common tasks, such as creating a recordset, opening it, and displaying the records. Server behaviors let you automate these common tasks with robust, standard code so that you can concentrate on the difficult parts.

Hand coding unique pages gets the job done, but unless you are a Web design team of one, and you are sure no one else will want to modify the page after you have finished with it, I would recommend adding a custom server behavior. Even if you are the sole developer, you can save yourself time in the long run by creating your own server behaviors.

Writing Server Behaviors

To write your own server behaviors is relatively simple, but you do need to be familiar with hand coding the functionality you want. You should first hand code the function you want to use and run the page to check that it works properly. After writing the behavior, you should use it again to check that all is well.

We are going to write two simple behaviors that read and write cookies, using VBScript for ASP. Even if you are not yet familiar with ASP, you should be able to follow along.

Writing a Cookie Behavior

Cookies are sent by the server to the client along with the requested page. If the cookie is given an expiration date, the client's browser will save the cookie on the client's machine so it can be referred to during future visits to the Web site. The client will send the cookie back to the server with each page request and form submission, and a server-side script can use this cookie value as part of the dynamic page-generation process. Although cookies are sent and processed by the server, you can also read and write cookies, using JavaScript, after the page has arrived at the client. Dreamweaver includes two code snippets to read and write cookies using JavaScript.

You are going to write your cookies from the server (using ASP), so you do not have to rely on the browser supporting JavaScript. The code is also much easier when done from the server side.

This behavior will save the value of a recordset column into a cookie on the user's machine. You will also write a behavior to read this cookie value, on subsequent pages or even site visits.

To start to write the behavior, open up the Application panel as shown in Figure B.13 and click the Server Behaviors tag. Click the plus button and choose New Server Behavior.

Figure B.13. Choose New Server Behavior from the Add Behavior menu to start writing your behavior.

graphics/bfig13.jpg

You will now be presented with the New Server Behavior dialog box as shown in Figure B.14. Choose the document type you want to use (Dreamweaver should guess from the site you have open) and give the behavior a name. For this example, use Write Cookie (spaces are allowed here). Remember that other people are going to use the behavior, so make it descriptive of its function. This is a completely new behavior, so do not select the option box at the bottom of the box. click OK.

Figure B.14. Give your new behavior a descriptive name for others to use.

graphics/bfig14.jpg

The next dialog box is shown in Figure B.14. This is where most of the work will be done. You will write blocks of code here and tell Dreamweaver where you want the code to be written on the page.

Add a code block by clicking the plus button on the top left. The suggested name is fine, so accept that.

The Code Block window asks you to replace the text with your own code. This is what you will do, inserting the ASP code that will write a cookie, as you can see from Figure B.15. The code is

 <%Response.Cookies("cookiename") = "cookievalue"  Response.Cookies("cookiename").Expires = #12/31/2005# %> 
Figure B.15. Add a code block and give it a name.

graphics/bfig15.jpg

This will write a cookie called "cookiename," with a value of "cookievalue" to the client, which will expire at the end of 2005. You can directly type the code in, if you are confident it will work, or copy and paste it from another file.

Figure B.16. Put the ASP code to write the cookie in the Code Block box.

graphics/bfig16.jpg

Using Parameters

The code is correct and will write a cookie to the client, but the cookie will always be called cookiename and its value will always be cookievalue. You want to let the designers add their own cookie names and values. To do this, use Parameters.

To make the cookie name a choosable parameter, highlight the code cookiename. Click the Insert Parameter in Code Block button and enter a descriptive parameter name in the dialog box shown in Figure B.17. Remember that other designers will enter their own values for this parameter, so it should be clear what value they are setting. In this case, choose CookieName. Parameter names cannot have spaces.

Figure B.17. Give the parameter a descriptive name other Web designers will need to enter their own values.

graphics/bfig17.jpg

Click the OK button to dismiss the dialog box. You will be asked if you want to replace all instances of the word "cookiename" with the new parameter; click Yes. If you now look at the code, you will see that cookiename has been replaced with @@CookieName@@. This indicates to Dreamweaver that a parameter goes here.

Now add another parameter for the cookie value. Again highlight the word cookievalue and click the Insert Parameter in Code Block button. Call the parameter CookieValue. If you examine the code, you will see that cookievalue has been replaced with @@CookieValue@@. Double-check that you still have the quotation marks in your code, as shown in Figure B.18. The expiration date is still "hard-coded" and set well into the future, which is perfectly acceptable you don't want to confuse the designers with too many choices, or run the risk of them entering a date in the wrong format.

Figure B.18. Parameters are marked in the code with double At (@) symbols.

graphics/bfig18.jpg

Code Placement

The next option to set is where you want Dreamweaver to put the code that the behavior will insert. Writing and reading cookies should be done at the beginning of a page and must be done before the browser is sent anything even a doctype or <HTML> tag. This cookie value comes from a recordset, so it can be set only after the recordset has opened.

Choose Above the HTML Tag from the Insert Code menu, and the Relative Position will be Just After the Recordsets, as shown in Figure B.19.

Figure B.19. You need to specify where the code will be inserted by Dreamweaver. The Insert Code menu specifies the approximate position, which can be set more precisely with the Relative Position menu.

graphics/bfig19.jpg

NOTE

You can choose Custom Position and give the code block a weight. The code that opens a recordset has a weight of 50, so if you want the code to execute before the recordset opens, give it a weight of less than 50, and if the code depends on the recordset being open and therefore must execute after the open recordset code, give it a weight of more than 50.


After you have positioned the code block, click the Next button. This closes the Server Behavior Builder dialog box and opens the Generate Behavior dialog box. In this box, you can specify how designers will enter parameter values. After the designer chooses the server behavior, a dialog box will pop up, and it is here that you specify what it looks like. Each parameter can be entered with many types of interface controls.

With the up/down arrows at the top left of the list, you can change the order in which parameters are listed. Select a parameter name to move it. The arrow to the right of the name allows you to choose the type of interface control that will select the value. For the cookie name, use the default text box, and because you want to set the value from a recordset, the cookie value will use a Dynamic Text Field control.

As you can see from Figure B.20, you can choose from a wide variety of controls. You should choose the best control to minimize the possibility of invalid values being entered by designers through typing errors. After you have made your choice, click OK to dismiss the dialog box.

Figure B.20. You can choose the type of interface control that will be presented to designers when they enter parameter values.

graphics/bfig20.jpg

Using Your New Server Behavior

The new server behavior is now available in any ASP/VB Script site. If you now click the plus button on the Server Behavior tag, the drop-down menu shows the new server behavior, as you can see in Figure B.21.

Figure B.21. The new server behavior can be seen in the Add Behavior menu.

graphics/bfig21.jpg

If you choose the new behavior, you are presented with a dialog box to enter the cookie name into a text box and to choose the cookie value from a list of fields in the recordset, as you can see in Figure B.22.

Figure B.22. The new server behavior lets designers enter their own cookie names and choose a field for the cookie value.

graphics/bfig22.jpg

You should test that the behavior works on your page.

Another Server Behavior to Read the Cookie

To complete the cookie exercise, you need to read the cookies you have written. You can write a behavior that assigns the value of a cookie to a variable name chosen by the designer. This variable can be used for dynamically producing other page content.

You can enter Dreamweaver parameters directly into your code; remember that a parameter starts and finishes with double At signs. The code to read the cookie, including Dreamweaver parameters, is

 <%@@variablename@@= request.cookies("@@CookieName@@")%>  

Again, click the plus button on the Server Behavior tab and choose New Server Behavior. Call the new behavior Read Cookie and add a new code block. Enter the preceding code into the Code Block window, which automatically adds Dreamweaver parameters. The block should be positioned above the <HTML> Tag, and near the beginning of the file. The completed dialog box is shown in Figure B.23.

Figure B.23. Add the cookie-reading code to the Code Block window to continue writing the new behavior.

graphics/bfig23.jpg

After you click Next, both parameter values should be entered using text boxes, as you can see from Figure B.24.

Figure B.24. The parameter values of the Read Cookie behavior will be entered by the designer using the default text boxes.

graphics/bfig24.jpg

The second behavior to read a cookie and assign its value to a variable is complete. The new behavior should be tested out on a page.

Editing and Removing Custom Behaviors

If the behavior does not work properly and needs to be edited, or if you want to remove the behavior completely, on the Add Behavior menu choose Edit Behavior.

From this dialog box, you can remove the behavior with the Remove button, or Edit it using the Edit button that can be seen in Figure B.25. After you click the Edit button, you will receive a warning that you may corrupt the way the behavior is displayed by editing it.

Figure B.25. Behaviors can be edited and removed by choosing Edit Behavior from the Add Behavior drop-down menu.

graphics/bfig25.jpg


    Team-Fly    
    Top


    Macromedia Dreamweaver MX Unleashed
    Macromedia Dreamweaver MX 2004 Unleashed
    ISBN: 0672326310
    EAN: 2147483647
    Year: 2002
    Pages: 321

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net