Wile Adobe dreamweaver CS5 Bible phần 10 ppt

Inserting and removing server behaviors To add a particular server behavior to your page, click the Add + button in the Server Behaviors panel and select the desired behavior from the l

adobe strongly cautions programmers against using documentEdited() and selectionChanged()

unless these functions are absolutely necessary Because they constantly monitor the document, both

func-tions can have an adverse effect on performance if implemented adobe suggests that programmers

incor-porate the setTimeout() method to temporarily pause these functions so that the user can continue to

interact with the program n

Within the Dreamweaver API are two pairs of methods and a single function that relate

L

to floating panels as follows:getHideAllFloaters(): Reads the state of the Show/

Hide Floating Panel menu option to determine if all floating panels should be hidden (true) or shown (false)

setHideAllFloaters()

L : Sets the Show/Hide Floating panel to a particular state, to

Hide (true) or Show (false)

getFloaterVisibility(floaterName)

L : Reads whether the given floating panel is

currently displayed and frontmost (true) or hidden (false)

setFloaterVisibility(floaterName,isVisible)

panel forward if the isVisible argument is truetoggleFloater(floaterName)

L : Toggles the visibility state of the given floating panel

between hiding and bringing to the front

Floating panels have a great deal of potential with their flexible interface and constant onscreen

presence The example shown in Figure 33-7, PalettePicker from WebAssist, interfaces with

Adobe Kuler to access color themes

Figure 33-7

The custom floater, PalettePicker by WebAssist, displays color themes created for Adobe Kuler

Developing Translators

For any markup tag to be depicted in the Document window — whether it’s <b> for bold or a

cus-tom third-party tag such as Tango’s <@cols> — it must be translated Dreamweaver’s built-in

ren-dering system translates all the standard HTML code, along with a few special custom tags such as

those for ASP and ColdFusion However, to display any other custom tags, or those that perform

special functions such as server-side includes, the tag developer must build a custom translator.

As part of its expansion efforts, Dreamweaver supports custom translators This enhancement

enables programs that output nonstandard HTML to be displayed onscreen integrated with the

regu-lar code One of Dreamweaver’s main claims to fame is its capability to accept code without rewriting

it With Dreamweaver translators, you can visually insert, show, and edit your custom code.

Here’s a brief overview of how translators work:

1. When Dreamweaver starts, all the properly coded translators in the Dreamweaver CS5\

Configuration\Translators folder are initialized.

2. If a document is loaded with nonstandard HTML, the code is checked against the

installed translators.

3. The translators are enabled.

Note

With the exception of the ssI translator, all translators are automatically active all the time — no preference

setting determines their availability n

4. The code is processed with the translator and temporarily converted to a format able to Dreamweaver.

accept-5. Dreamweaver renders the code onscreen.

6. If a change is made to the page, Dreamweaver retranslates the document and refreshes

the screen.

7. When the page is saved, the temporary translation is discarded, and the original code, with any modifications, is stored.

Developers continue to break new ground with the use of translators Some translators that have

been developed so far include those for the following:

Server-side includes:

L Standard with Dreamweaver, the SSI translator effortlessly inserts, at design time, files that you normally don’t see until delivered by the Web server (To learn more about SSI, see Chapter 29.)

XSSI:

L The Extended Server-Side Include (XSSI) extension, developed by Webmonkey authors Alx Ladygo, Nadav Savio, and Taylor for Adobe, includes a translator that brings the Apache-served code right into the Document window.

Translator functions

Like other Dreamweaver extensions, such as behaviors and commands, translators are HTML

files with JavaScript Translators have no user interface Other than deciding when to invoke it,

you have no parameters to set or options from which to choose All the pertinent code is in a

script located in the <head> of the translator, which, along with any necessary support routines,

includes two essential JavaScript functions: getTranslatorInfo() and translateMarkup()

Any other Dreamweaver JavaScript API functions not specific to behaviors can be used in a

trans-lator as well.

Note

Because of the limitations of Javascript, much of the heart of custom translation is handled by specially

writ-ten C-level exwrit-tensions These compiled code libraries enhance Dreamweaver’s capabilities so that new data

types can be integrated C-level extensions are covered in the “Extending C-Level Libraries” section later in

this chapter n

The getTranslatorInfo() function

The getTranslatorInfo() function simply sets up and returns an array of text strings that are

read by Dreamweaver during initialization.

The structure of the array is relatively rigid The number of array elements is specified when the

Array variable is declared, and a particular text string must correspond to the proper array

ele-ment The array order is as follows:

translatorClass:

L The translator’s unique name used in JavaScript functions The name

has to begin with a letter and can contain alphanumeric characters as well as hyphens

or underscores.

title:

L The title listed in the menu and the Translation category This text string can be

no longer than 40 characters.

nExtensions:

L The number of file extensions, such as .cfml, to follow This declaration

tells Dreamweaver how to read the next portion of the array If this value is set to 0, all files are acceptable.

extension:

L The actual file extension without the leading period.

nRegExps:

L The number of regular expressions to be declared Should this value be

equal to 0, the array is closed.

The number of array elements — and thus, the detail of the function — depends entirely on the

translator Here, for example, is the code for getTranslatorInfo() from Live Picture’s

transla-tor, where a file must have a particular <meta> tag to be translated:

function getTranslatorInfo(){

returnArray = new Array( 5 );

returnArray[0] = “FPX”; // translatorClass returnArray[1] = “Flashpix Image Translator”; // title returnArray[2] = “0”; // number of extensions returnArray[3] = “1”; // number of expressions returnArray[4] = “<meta http-equiv=\”refresh\” content=\”0;url=http://”;

return returnArray;

}

By comparison, the standard SSI translator’s getTranslatorInfo() function has 10 array

ele-ments, and Webmonkey’s XSSI has 17.

The translateMarkup() function

Although the getTranslatorInfo() function initializes the translator, the translateMarkup()

function actually does the work As noted earlier, most translators rely on a custom C-level

extension to handle the inner workings of the function, but translateMarkup() provides the

JavaScript shell.

The translateMarkup() function takes three arguments, which must be declared, but whose

actual values are provided by Dreamweaver:

L : A text string with the code for the page to be translated.

Typically, the docContent text string is parsed using either JavaScript or a C-level extension

within the translateMarkup() function that returns the translated document Dreamweaver

then displays this translated document.

Here’s an excerpt of the translateMarkup() function from the ColdFusion translator:

function translateMarkup(docNameStr, siteRootStr, inStr) { var outStr = “”;

// translate

if (inStr.indexOf(“<cf”) != -1 || inStr.indexOf(“<CF”) != -1) { var TM =

new TranslationManager(TRANSLATOR_CLASS, SERVER_MODEL_FOLDER, “”);

TM.serverModelAlwaysCheckTag = myAlwaysCheckTag;

var split = TranslationManager.splitBody(inStr);

In this example, notice that the translated document in the form of outStr is built by creating

a TranslationManager object named TM and then calling this object’s translate() method:

TM.translate(split.inStr).

Locking code

Translations are generally intended for onscreen presentation only Although there’s no rule

pro-hibiting translated content from being written out to disk, most applications need the original

content to run To protect the original content, Dreamweaver includes a special locking tag This

XML tag pair, <MM:BeginLock> <MM:EndLock>, stops the enclosed content (the translation)

from being edited, while simultaneously storing a copy of the original content in a special format.

The <MM:BeginLock> tag has several attributes:

L : A comma-separated list of any files on which the locked content depends If

any of these dependent files are altered, the page is retranslated.

orig

L : A text string with the original markup before translation The text string is

encoded to include four standard HTML characters:

To see how the special locking tag works, look at an example taken from the Tango Sample

Data translator Tango uses what are called meta tags, which begin with an @ sign, such as the

<@TOTALROWS> tag The Tango Sample Data translator replaces a result drawn from a database

with a specified sample value The original code is:

<@TOTALROWS samptotalrows=23>

After the code is translated, Dreamweaver refreshes the screen with the following code:

<MM:BeginLock translatorClass=”TANGO_SAMPLEDATA” type =”@TOTALROWS”

orig=”%3C@TOTALROWS samptotalrows=23%3E”>23<MM:EndLock>

The 23 in bold is the actual translated content that appears in Dreamweaver’s Document window.

Note

You don’t actually see the locking code, even if you open the Code inspector when a page is translated To

view the code, select the translated item, copy it, and then paste it in another text application, or use the

Paste as hTML feature to see the results in Dreamweaver n

Extending C-Level Libraries

All programs have their limits Most limitations are intentional and serve to focus the tool for

a particular use Some limitations are accepted because of programming budgets — for both

money and time — with the hope that the boundaries can be exceeded in the next version

With Dreamweaver, one small section of those high, sharply defined walls has been replaced

with a doorway: C-level extensions With the proper programming acumen, you can customize

Dreamweaver to add the capabilities you need.

As with most modern computer programs, the core of Dreamweaver is coded in C and C++, both

low-level languages that execute much faster than any noncompiled language, such as JavaScript

Because C is a compiled language, you can’t just drop in a function with a few lines of code and

expect it to work — it has to be integrated into the program The only possible way to add

sig-nificant functionality is through another compiled component called a library With the C-level

extensions capability, Dreamweaver enables the incorporation of these libraries, known as DLLs

(Dynamic Link Libraries) on Windows systems and as CFMs (Code Fragment Managers) on

Macintosh systems.

One excellent example of the extended library is DWfile This C-level extension is used by

sev-eral Dreamweaver partners, including RealNetworks and iCat, to perform tasks outside the

capa-bilities of JavaScript — namely, reading and writing external text files By adding that one library,

Dreamweaver can now work with the support files necessary to power a wide range of associated

programs DWfile is described in detail in the following section.

C-level extensions are also used in combination with Dreamweaver’s translator feature As

dis-cussed earlier in this chapter, translators handle the chore of temporarily converting nonstandard

code to HTML that Dreamweaver can present onscreen — while maintaining the original code

in the file Much of this functionality isn’t impossible for JavaScript; the conversion would be too

slow to be effective C-level extensions are definitely the way to go when looking for a powerful

solution.

a discussion of programming in C or C++, as required by C-level extensions, is beyond the scope of this book

Developers are encouraged to scour the Dreamweaver support Center for relevant information: www.adobe

.com/support/dreamweaver/ n

Calling C-level extensions

C-level extensions, properly stored in the Dreamweaver CS5\Configuration\JSExtensions folder,

are read into Dreamweaver during initialization when the program first starts The routines

contained within the custom libraries are accessed through JavaScript functions in commands,

behaviors, objects, translators, and other Dreamweaver extensions.

Take a look at how Adobe’s C-level extension DWfile is used DWfile has 14 main functions:

copy()

L : Copies a file from one file URL (the first argument) to another (the second

argument) DWfile.copy() can be used to copy any type of file, not just text files.

createFolder()

L : Creates a folder, given a file URL.

listFolder()

L : Lists the contents of a specified folder in an array This function takes

two arguments: the file URL of the desired folder (required) and a keyword, either

“files” (which returns just filenames) or “directories” (which returns just tory names) If the keyword argument is not used, you get both files and directories.

direc-exists()

L : Checks to see if a specified filename exists This function takes one

argu-ment, the filename.

getAttributes()

L : Returns the attributes of a specified file or folder Possible

attri-butes are R (read-only), D (directory), H (hidden), and S (system file or folder).

L : Returns the JavaScript object that represents the date when

the file was initially created.

getModificationDate()

L : Returns the date a specified file or folder was last modified.

getModificationDateObj()

L : Returns the JavaScript object that represents the date a

specified file or folder was last modified.

getSize()

L : Gets the size of a specified file.

read()

L : Reads a text file into a string for examination This function also takes one

argument, the filename.

write()

L : Outputs a string to a text file This function has three arguments; the first

two — the name of the file to be created and the string to be written — are required

The third, the mode, must be the word append This argument, if used, causes the string to be added to the end of the existing text file; otherwise, the file is overwritten.

remove()

L : Places the referenced file in the Recycling Bin (Windows) or Trash

(Macintosh) without requesting confirmation.

The following JavaScript function, which could be included in any Dreamweaver extension, uses

DWfile to determine whether theFile, named in a passed argument, exists If it does, the

con-tents are read and presented in an alert box; if theFile doesn’t exist, the function creates it and

outputs a brief message.

function fileWork(theFile) { var isFile = DWfile.exists(theFile); // does theFile exist?

if (isFile) { alert(DWfile.read(theFile)); // yes: display it in an alert box }

else { // no: create it and display msg DWfile.write(theFile,”File Created by DWfile”);

}}

Note how the C-level extension name, DWfile, is used to call the library and its internal

func-tions After the library has been initialized, it can be addressed as any other internal function,

and its routines are simply called as methods of the function using JavaScript dot notation, such

as DWfile.exists(theFile).

Building C-level extensions

You must follow strict guidelines to enable Dreamweaver to recognize a C-level extension

Specifically, you must include two files in the library, and you must declare each function for

cor-rect interpretation by Dreamweaver’s JavaScript interpreter.

Adobe engineers have developed a C-Level Extension API in the form of a C header, mm_jsapi.h,

that contains definitions for more than 20 data types and functions To insert mm_jsapi.h in

your custom library, add the following statement:

#include “mm_jsapi.h”

Tip

You can find the latest version of mm_jsapi.h on the Dreamweaver Exchange, which you can get to by

choosing help ➪ Dreamweaver Exchange in Dreamweaver or by loading the UrL www.adobe.com/

exchange/dreamweaver in your browser n

After you’ve included the JavaScript API header, you declare a specific macro, MM_STATE This

macro, contained within the mm_jsapi.h header, holds definitions necessary for the integration of

the C-level extension into Dreamweaver’s JavaScript API You must define MM_STATE only once.

Each library can be composed of numerous functions available to be called from within

Dreamweaver For Dreamweaver’s JavaScript interpreter to recognize the functions, each one

must be declared in a special function, JS_DefineFunction(), defined in the library All

the JS_DefineFunction() functions are contained in the MM_Init() function The syntax

where jsName is the JavaScript name for the function, call is a pointer to a C-level function,

and nArgs is the number of arguments that the function can expect For example, the MM_

Init() function for DWfile might appear as follows:

Because MM_Init() depends on definitions included in the C header mm_jsapi.h, it must be

called after the header is included.

Tip

If you’re building cross-platform C-level extensions, consider using Metrowerks’ CodeWarrior integrated

development environment CodeWarrior can edit, compile, and debug C, C++, and even Java or Pascal

for both Windows and Macintosh operating systems Perhaps most important, adobe engineers used

CodeWarrior to test C-level extensions n

Customizing Your Tag Libraries

Previous versions of Dreamweaver required you to manually edit the sourceformat.txt

file to change code formatting, including tag case, attributes, indentation, and line wrapping

Dreamweaver gives you a well-designed dialog box called the Tag Library editor to make all those

changes for you You can use that editor to customize every single tag you place in Dreamweaver,

and you can even add additional tags if you’re using a proprietary server or design XML files with

commonly used tag sets.

All tag-related attributes and color code settings are stored in a tag database (the Tag Library),

which is manipulated through the Tag Library Editor Click the Tag Library Editor link in

Preferences or choose Edit ➪ Tag Libraries.

Editing tag libraries, tags, and attributes

To edit the properties for a tag library, follow these steps:

1. Choose Edit ➪ Tag Libraries to open the Tag Library Editor dialog box, and select the

tag library whose properties you want to set, as shown in Figure 33-8.

2. In the Used In list box, choose every type of document that should use the selected

tag library Note that the tags in the selected library are available only in the document types you’ve chosen.

You use the Tag Library Editor to customize Dreamweaver’s tag libraries

3. If the tags in the selected tag library require a prefix, enter this prefix in the Tag Prefix field The Tag Prefix box enables you to add a prefix to the beginning of every tag in that particular library For example, if you developed a tag library for XSL documents, you add xsl: as the tag prefix to add the prefix to the beginning of every tag.

4. When you are finished, click OK to close the Tag Library Editor dialog box.

To edit a tag in a tag library, follow these steps:

1. Choose Edit ➪ Tag Libraries In the Tag Library Editor dialog box, open a tag library and select the tag you want to edit.

2. Set your desired Tag Format options:

Line Breaks:

L Changing the line breaks option changes where Dreamweaver places line breaks in your code Choose between four options: No Line Breaks; Before And After Tag; Before, Inside, After; and After Tag Only This option is great for prevent- ing line breaks after <td> tags and before </td> tags to ensure that no unwanted whitespace shows up in your code.

Contents:

L This setting affects how the content inside your tags is formatted The indentation settings are based on your code format preferences Choose between Not Formatted, Formatted But Not Indented, and Formatted And Indented.

Case:

L The case settings affect how the tag and its attributes are capitalized XHTML, for example, requires that everything be lowercase Options are Default, Lowercase, Uppercase, and Mixed Case Choosing Mixed Case gives you a prompt to type in exactly how you want the tag to appear Clicking Set Default enables you to set the default for all tags, which is the same as changing your tag case preferences in Edit ➪ Preferences ➪ Code Format (Dreamweaver ➪ Preferences ➪ Code Format).

The Preview area below the Tag Format options enables you to see exactly how your tag will be written to the page.

Tip

I recommend setting your default case to lowercase to comply with XML/XhTML standards n

To edit an attribute for a tag, follow these steps:

1. Choose Edit ➪ Tag Libraries In the Tag Library Editor dialog box, open a tag library

and select the attribute you want to edit.

2. Set your desired attribute options:

Attribute Case:

L This option sets the case of your attribute Attribute Case is pletely independent of the tag Options are Default, Lowercase, Uppercase, or Mixed Case Choosing Mixed Case enables you to enter exactly how you want the attribute formatted Clicking Set Default alerts you to return to the Code Format category of Preferences.

com-Attribute Type:

L There are ten different attribute types for your tag — Text, Enumerated, Color, Directory, File Name, File Path, Flag, Font, Relative Path, and Style Setting the type affects how Dreamweaver asks for information when using Code Hints in Code view or the Quick Tag Editor Choosing Color for an attribute causes a color palette to appear if you add the attribute in Code view Setting the Type to Relative Path gives you a Select File dialog box.

Values:

L The Values field is used only for the enumerated attribute type and gives you

a list of valid values for a particular attribute.

3. Click OK.

Creating and deleting tag libraries, tags,

and attributes

The following sets of steps show you how to create a new tag library, add a tag to an existing

library, or add an attribute to an existing tag.

To add a new tag library, follow these steps:

1. Choose Edit ➪ Tag Libraries.

2. Click the Add (+) button and choose New Tag Library.

3. Enter a name for your new tag library and click OK.

4. Your new tag library is now shown at the bottom of the list You’re ready to start adding new tags.

To add new tags to one of your tag libraries, follow these steps:

1. Choose Edit ➪ Tag Libraries.

2. Click the Add (+) button and choose New Tags.

3. Choose the Tag Library to add to in the list menu.

4. Enter one or more tags to add To add several tags at one time, simply enter a separated list of tags into the dialog This method enables you to add a large number of tags very quickly.

comma-5. Choose whether your tag requires matching end tags Choosing matching end tags gives you tags like <a>text</a> Choosing not to have matching end tags gives you tags like

<br> and <img>.

To add a new attribute to an existing tag, follow these steps:

1. Choose Edit ➪ Tag Libraries.

2. Click the Add (+) button and choose New Attributes.

3. Choose the Tag Library that contains the tag you want to add attributes to from the first list menu.

4. Choose the tag you want to add attributes to from the second list menu.

5. Enter one or more attributes to add If you want to add several attributes at one time, simply enter a comma-separated list of attributes into the dialog This enables you to add a large number of attributes very quickly.

To delete a tag library, tag, or attribute, follow these steps:

1. Choose Edit ➪ Tag Libraries.

2. In the Tag Library Editor dialog box, select the tag library, tag, or attribute you want to

delete.

3. Click the Remove (–) button If you are asked to confirm the deletion, do so.

4. To make your deletions permanent, click OK To discard your deletions, click Cancel.

after you click that OK button, your deletions are permanent You cannot undo them, so ponder deeply

before clicking that mouse or you could be forced to reinstall! n

Importing a DTD or schema to create a new tag library

Dreamweaver enables you to create a new tag library by importing tags from an existing XML

Document Type Definition (DTD) file or schema In many instances, you may want to add a

new tag library If you’re working on a proprietary server or a language that’s not supported by

Dreamweaver, you can add all the necessary tags into a new tag library.

To create a new tag library by importing a DTD file or schema, follow these steps:

1. Choose Edit ➪ Tag Libraries.

2. In the Tag Library Editor dialog box, click the Add (+) button and choose DTDSchema ➪

Import XML DTD or Schema File.

3. In the File Or Remote URL field, enter the file or URL of the DTD or schema file.

4. In the Tag Prefix field, enter the prefix to be used with the tags you’re importing, to

identify the tags as part of this tag library.

5. When you’re finished, click OK to create your new tag library.

Summary

Dreamweaver’s commitment to professional Web site authoring is most evident when you

exam-ine the program’s customization capabilities Virtually every Web site production house can

benefit from some degree of personalization — and some clients absolutely require it As you

examine the ways in which you can make your productive life easier by extending Dreamweaver,

keep the following points in mind:

Dreamweaver includes a full range of customizable features: objects, behaviors,

Attributes for third-party tags are viewable — and modifiable — by creating a custom

L

Property inspector.

Dreamweaver’s C-Level Extensibility feature enables C and C++ programmers to add

L

new core functionality to a program.

Tags from server-side applications can be viewed in the Document window, just as they

Working with Dreamweaver’s server behaviors

adding new server behaviors Crafting custom server behaviors

S erver behaviors are the heart of Dreamweaver, the essential engine

that puts the dynamic in dynamic Web applications Server behaviors

insert server-model–specific code that handles everything from

dis-playing dynamic data to authenticating users Even the basic data source

connection and the establishment of a recordset are, in reality, server

behaviors Without server behaviors, no dynamic capabilities would be

possible in Dreamweaver.

Server behaviors are valuable for novices and veteran coders alike They

enable designers who have never heard of an ASP Request collection to gather

information from a form — a procedure that utilizes the ASP Request

collection — with point-and-click ease Even serious code jockeys can

appreciate the productivity potential of server behaviors, especially the

capability to create their own With the Server Behavior Builder,

program-mers can build a library of their custom functions, complete with fully

functional dialog boxes for maximum flexibility After these functions are

crafted, you can drop any of the custom server behaviors directly onto the

page — and, if need be, easily alter the parameters.

This chapter includes an overview of server behaviors as well as basic

infor-mation about their use and management For your reference, you also find a

detailed description of each of the standard Dreamweaver server behaviors

Finally, you look at ways to extend Dreamweaver’s core functionality with

the Server Behavior Builder.

Understanding Server Behaviors

In contrast to Dreamweaver’s JavaScript behaviors — with their numerous required functions

and many more optional ones — a server behavior may be as simple as one line of code The

dif-ference, and it’s a key one, is that the code is intended to be executed by the application server,

not the browser.

Another difference between server behaviors and JavaScript behaviors is that server behavior

code may exist outside the bounds of the HTML page Any page with a recordset has a section of

code before the opening <html> tag, and a smaller block of code after the closing </html> tag

Dreamweaver automatically places the code in the proper place — and code placement is very

important on the server side — when any of its standard server behaviors are used Dreamweaver

includes more than 25 standard server behaviors; the exact number varies for each server model

Figure 34-1 displays the available server behaviors for ASP.

Figure 34-1

Apply any server behavior from the Server Behaviors panel

The Server Behaviors panel is the focal point for inserting, removing, and managing server

behaviors Unlike the Behaviors panel, which displays only the JavaScript behaviors attached

to the selected tag, the Server Behaviors panel displays all the server behaviors included in the

current page, in the order in which they were applied Selecting a specific server behavior listed

in the Server Behaviors panel highlights the attached page element, if visible in the Document

window Some server behaviors, such as Recordset, have their own Property inspector, whereas

others display dynamic code as an attribute in a text or other Property inspector.

Although the simplest server behaviors can insert code without any additional user input, each

built-in server behavior has a dialog box for specifying parameters These vary in complexity

from a single drop-down list to multiple-section dialog boxes with every type of input element

available As you learn in the next section, after you have inserted a server behavior, you can

eas-ily modify its parameters.

Applying and Managing Server Behaviors

If you have ever completed any Web applications in Dreamweaver, you’ve likely already

discov-ered how to apply and update a server behavior The Server Behaviors panel is the primary tool

for inserting, modifying, and removing server behaviors You can display the Server Behaviors

panel in several ways:

The Server Behaviors panel remains available regardless of whether you are in Design view, Code

view, or the split-screen Code and Design view.

Inserting and removing server behaviors

To add a particular server behavior to your page, click the Add (+) button in the Server Behaviors

panel and select the desired behavior from the list Many of the server behaviors have prerequisites —

such as a recordset, form, or selected element — that must be in place before they can be installed,

but these requirements vary from server behavior to server behavior If you attempt to insert a server

behavior and some precondition has not been met, Dreamweaver alerts you to the missing element;

you are prevented from inserting the server behavior until all the required pieces are in place.

After you select the server behavior from the Add drop-down list, a dialog box appears to enable

you to select or enter the needed parameters Each dialog box is specific to the chosen server

behavior, and they vary widely in terms of parameters offered and complexity For information

about a specific server behavior, see the corresponding section for that server behavior later in

Removing an existing server behavior is simple Select the entry for the server behavior in the

Server Behaviors panel and click the Remove (–) button Dreamweaver immediately removes all

the associated code without requesting confirmation.

Caution

With Javascript behaviors, if you delete a page element that has a client-side behavior attached, you

automat-ically delete that behavior This is not always the case with server behaviors, and it’s best to always use the

server Behaviors panel’s remove (–) button before deleting any associated text, graphics, or form elements n

Editing the parameters

To modify the attributes or parameters of an inserted server behavior, double-click its entry

in the Server Behaviors panel You can differentiate between multiple applications of the same

server behavior in two ways First, the entry for each server behavior lists one or two of its key

attributes in parentheses For example, a Dynamic Text server behavior applied to the LastName

column in the rsMaillist recordset is displayed as follows:

Dynamic Text(rsMaillist.LastName)

Second, you can tell which server behavior is associated with which page element by

select-ing the server behavior — the associated text, graphic, or other page element is also selected in

Design or Code view.

When the dialog box for a server behavior reopens, you can alter any of the parameters that

remain active In some situations, as with the Go To Detail Page server behavior shown in

Figure 34-2, one or more fields may be disabled and so rendered unable to be changed If you

need to alter a disabled parameter, delete the server behavior and reapply it.

Figure 34-2

When modifying certain server behaviors, some fields, such as the Link field in this Go To Detail Page

dia-log box, are disabled and cannot be changed

Standard Server Behaviors

Dreamweaver ships with more than 25 server behaviors, and it offers the option to add many

more The default server behaviors are geared toward handling basic Web application tasks such

as repeating an area and inserting records in a data source.

In the following sections, each server behavior is briefly described, along with any prerequisites

Step-by-step instructions for including the server behavior are provided; for more contextual

information on using the particular server behavior, see the cross-referenced chapter.

Recordset (Query)

To create a simple recordset, follow these steps:

1. From the Server Behaviors panel, click the Add (+) button and choose Recordset (Query) from the drop-down list The Recordset dialog box, shown in Figure 34-3, is displayed.

Figure 34-3

You can add recordsets from either the Server Behaviors panel or the Bindings panel through two different

dialogs; the Simple Recordset dialog is shown here

2. In the Recordset dialog box, enter an identifying label for your recordset in the Name

field It’s considered good practice to prefix your recordset name with rs — as in rsDBA This prefix quickly identifies the recordset in the code.

3. Select a connection from the drop-down list of that name.

4. If the desired connection has not been declared, click Define to open the Connections

5. Select a table to work with from the Tables drop-down list The chosen table’s fields are

displayed in the Columns list.

6. By default, all the columns are included in the recordset To specify certain columns,

choose the Selected option and select any desired field Shift+click to select contiguous columns, and Ctrl+click (Command+click) to select noncontiguous columns.

7. By default, all the records in the selected columns are available To limit the recordset

further, use the four Filter drop-down lists as follows:

Choose the field on which you want to base your filter from the first drop-down list

L

This list changes dynamically according to which table you’ve selected.

From the second drop-down list, select the expression with which to compare the

L

data from the selected column in the first drop-down list Available expressions are

=, >, <, >=, <=, <>, Begins With, Ends With, and Contains.

Choose the type of value to compare to the selected field from the third drop-down

entered are not case-sensitive.

8. To sort the data, select a column from the first drop-down list under Sort and choose

either Ascending or Descending from the second list.

9. At any time, you can see what results will be returned for the recordset by clicking Test.

Tip

To see how your simple recordset translates into sQL, click the advanced button You can return to the

origi-nal dialog box by clicking simple on the advanced recordset dialog box n

10. Click OK when you’re finished.

Cross-Reference

For more information on defining recordsets, see Chapter 18 n

Repeat Region

The Repeat Region server behavior replicates a selected page area as many times as specified If the

Repeat Region surrounds dynamic data, the record pointer advances for each repetition A tab

and highlight note the boundaries of the Repeat Region when the Invisible Elements option

is enabled.

Requirements: One or more selected page elements, such as a table row or a line ending

in a line break tag (<br>).

To implement a Repeat Region, follow these steps:

1. Select the dynamic data and the surrounding code you’d like to repeat.

2. From the Server Behaviors panel, click the Add (+) button and select Repeat Region

from the list.

The Repeat Region dialog box, shown in Figure 34-4, appears.

Figure 34-4

With the Repeat Region server behavior, you can show some or all of the records in the chosen recordset

3. From the Repeat Region dialog box, choose the recordset you want to work with from the Recordset list.

4. If you want to display a subset of the recordset, enter the number of records you’d like

to display in the Show Records field.

5. If you want every record in the recordset to be displayed, choose the Show All Records option.

6. Click OK when you’re done.

Cross-Reference

For more information on the repeat region server behavior, see Chapter 20 n

Recordset Paging

The Recordset Paging server behaviors move the record pointer to the indicated data record in a

given recordset They are frequently used in combination to navigate through a recordset In all,

five Recordset Paging server behaviors exist; however, you insert the following four in an

The fifth server behavior in this category, Move To Specific Record, uses a different procedure,

which is covered in the following section.

Requirements: A selected page element and at least one recordset with more than one

returned row.

To use any of the four basic Recordset Paging server behaviors, follow these steps:

1. Select the text or image to which you’d like to attach the server behavior.

2. From the Server Behaviors panel, click the Add (+) button and choose the desired

behavior from the Recordset Paging submenu The appropriate Recordset Paging dialog box appears Your selection is highlighted in the Link list, as shown in Figure 34-5.

Figure 34-5

The Recordset Paging server behaviors (such as Move To Last Record) identify your selected target, which

may be an image or text

3. Make sure that the link selected is one of those showing in the Link list.

4. Choose the recordset you want to work with from the Recordset drop-down list.

5. Click OK when you’re finished.

Cross-Reference

For more information on these recordset paging server behaviors, see Chapter 20 n

Move To Specific Record

The Move To Specific Record server behavior is used after a recordset has been created to

navi-gate through the records To use the Move To Specific Record server behavior (not available in

ColdFusion or PHP), follow these steps:

1. Select the text or image to which you’d like to attach the server behavior.

2. From the Server Behaviors panel, choose Move To Specific Record from the Recordset

Paging submenu The Move To Specific Record dialog box is displayed, as shown in Figure 34-6.

An alternative method for creating a detail page uses the Move To Specific Record server behavior

3. Select the desired recordset from the list labeled Move To Record In.

4. Choose the field referenced in the URL parameter from the Where Column field.

5. Enter the variable in the URL parameter in the Matches URL Parameter field.

6. Click OK when you’re finished.

Cross-Reference

For more information on the Move To specific record server behavior, see Chapter 22 n

Show Region

The Show Region server behavior displays an area of the screen if a particular condition is true

These are often called conditional regions A different set of server behaviors applies for each

Show Region If Not First Record

Requirements: One or more selected page elements and at least one recordset.

Applying a Show Region server behavior is straightforward Just follow these steps:

1. Select the page area you’d like to show conditionally.

2. From the Server Behaviors panel, click the Add (+) button and select one of the server

behaviors from the Show Region submenu The dialog box for the specific Show Region server behavior you chose is displayed, like the one shown in Figure 34-7 The dialog boxes for all the Show Region server behaviors are identical.

Figure 34-7

To use any of the Show Region server behaviors, just choose a recordset

3. Select the recordset on which to base the Show Region condition from the Recordset list.

4. Click OK when you’re finished.

Cross-Reference

For more information on the show region server behavior, see Chapter 20 n

Go To Detail Page

The Go To Detail Page server behavior is used in master-detail Web applications to navigate

from a chosen link on the master page to a designated detail page This server behavior passes

a unique record ID via the URL query string method The Go To Detail Page server behavior is

only available with ASP VBScript.

Cross-Reference

For more on master-detail Web applications, see Chapter 23 n

Requirements: A selected page element and at least one recordset.

To attach a Go To Detail Page server behavior, follow these steps:

1. Select the page element — text, graphic, or dynamic data — you’d like to use as the link

to the detail page.

2. From the Server Behaviors panel, click the Add (+) button and select Go To Detail Page

from the drop-down list The Go To Detail Page dialog box, shown in Figure 34-8, is displayed.

Figure 34-8

Specify the linking parameter sent from the master page in the Go To Detail Page server behavior

3. Make sure that the page element selected is represented in the Link field If no selection was made, Dreamweaver creates a new Detail text link.

4. Enter the path to the detail page in the Detail Page field or click Browse to locate the file

in the Select File dialog box.

5. Enter the variable name you’d like to be sent in the Pass URL Parameter field You can use a name of your own choosing or the name of the field in the database Whichever name you decide upon, make a note of it somewhere because you need to reference it when the detail page itself is constructed.

6. Select the recordset of the URL parameter from the Recordset list.

7. From the Column list, choose the field to which the URL parameter’s value is related.

8. Unless you have preexisting URL or Form parameters to send to the detail page, leave

the Pass Existing Parameters options unchecked.

9. Click OK when you’re finished.

Go To Related Page

The Go To Related Page server behavior links to a new page that conveys the form and/or URL

variables previously passed to the current page.

Requirements: A selected page element and at least one recordset The page on which

the server behavior is inserted must have had form or URL values passed to it.

To attach a Go To Related Page server behavior, follow these steps:

1. Select the page element — text, image, or dynamic data — you’d like to use as the

trigger for your behavior.

2. From the Server Behaviors panel, click the Add (+) button and select Go To Related Page

from the list The Go To Related Page server behavior dialog box appears, as shown in Figure 34-9.

Figure 34-9

The Go To Related Page server behavior can convey form values, URL values, or both to another dynamic

page

3. In the dialog box, verify that the text or code for the selected element displayed in the

Link field is correct.

4. Enter the path to the target page in the Related Page field or click Browse to locate an

existing dynamic page.

5. If you want to carry over values received from a query string, select the URL Parameters

option.

6. If you want to pass values received from a form, select the Form Parameters option.

7. Click OK when you’re finished.

Cross-Reference

For more information on the Go To related page server behavior, see Chapter 22 n

Insert Record

The Insert Record server behavior adds a new record to a chosen table in a data source.

Requirements: A form with form elements and a Submit button.

To add the Insert Record server behavior, follow these steps:

1. From the Server Behaviors panel, click the Add (+) button and select Insert Record The Insert Record dialog box appears, as shown in Figure 34-10.

Figure 34-10

Users may add new data directly to a connected data source

2. From the Insert Record dialog box, choose the connection from the drop-down list If

you need to establish a new connection, click Define.

3. Select the data table you want to use from the Insert table list.

4. Enter the path to the destination page in the After Inserting, Go To field, or click the Browse button to locate the file It’s important that you select a confirmation or other page to go to after the form is submitted If you don’t, no feedback is provided to the user, and no change is apparent.

5. Select the name of the form to be used from the Get Values From list If there is only one form on the page, the form is preselected.

6. For each object listed in the Form Elements area:

Select the data source field into which the form object’s value is to be inserted from

L

the Columns list.

Use the Update Record server behavior to modify existing records in a data source.

Requirements: A recordset, a form with form elements linked to the dynamic data,

and a Submit button.

To insert an Update Record server behavior, follow these steps:

1. From the Server Behaviors panel, choose Update Record The Update Record dialog box

appears, as shown in Figure 34-11.

Figure 34-11

With an Update Record server behavior, you can modify your data source remotely

2. From the Update Record dialog box, choose a connection from the drop-down list To

establish a new connection, click Define.

3. Select the data table you want to use from the Update table list.

4. Choose the data source on which to base your update from the Select Record From list.

5. Select the key field from the Unique Key Column list Dreamweaver attempts to detect whether the field is a number type and if so, selects the Numeric option.

6. Enter the path to the destination page in the After Updating, Go To field or click the

Browse button to locate the file.

7. Select the name of the form to be used from the Get Values From list If there is only one form on the page, the form is preselected.

8. For each object listed in the Form Elements area:

Select the data source field into which the form object’s value is to be inserted from

L

the Columns list.

Choose the data source type for the data from the Submit As list The options are

L

Text; Numeric; Date; Date MS Access; Checkbox Y, N; Checkbox 1,0; Check -1,0;

and Checkbox MS Access.

9. Click OK when you’re finished.

Cross-Reference

For more information on the Update record server behavior, see Chapter 22 n

Delete Record

The Delete Record server behavior is used to remove existing records from a data source.

Requirements: A recordset, a form, and a Submit button.

To attach a Delete Record server behavior to a form, follow these steps:

1. Make sure that a form exists on a dynamic page that includes at least one recordset.

2. From the Server Behaviors panel, choose Delete Record The Delete Record dialog box is

displayed, as shown in Figure 34-12.

3. PHP and ColdFusion users: Choose the desired option from the First Check If Variable

Is Defined List

Leave the entry set to Primary Key Value if you are using a form to confirm the deletion

If you want the deletion to occur without confirmation, choose another entry from the list such as URL Parameter or Form Variable.

4.

Maintain an up-to-date data source with the Delete Record server behavior, shown here for a PHP page

6. Select the key field from the Primary Key Column list Dreamweaver attempts to detect

whether the field is a number type and if it is, selects the Numeric option.

7. Choose the variable that holds the Primary Key value from that menu and enter the

name of the variable in the adjacent field

8. Enter the path to the destination page in the After Deleting, Go To field or click the

Browse button to locate the file.

9. Click OK when you’re finished.

Cross-Reference

For more information on the Delete record server behavior, see Chapter 22 n

User authentication

The World Wide Web is all about accessing information from anywhere in the world Sometimes,

however, you need to restrict access to certain areas of your site to authorized users Dreamweaver

supplies a full complement of server behaviors to support authenticating the user against a

speci-fied data source

Log In User

The Log In User server behavior redirects authorized users to one page and unauthorized users to

another and creates a session variable for the username.

Requirements: A recordset, a form, appropriate form elements for a username and a

password, and a Submit button.

1. From the Server Behaviors panel, click the Add (+) button and choose User Authentication ➪

Log In User The Log In User dialog box is displayed, as shown in Figure 34-13.

2. If there is more than one form on the page, select the form containing the username and

password fields from the Get Input From Form list.

The Log In User server behavior verifies that the user may be granted access

3. Select the form element used to gather the username from the Username Field list.

4. Select the form element used to gather the password from the Password Field list.

5. Choose a connection to the data source containing the table of registered users from the Validate Using Connection list.

6. Select the table of registered users from the Table list.

7. Choose the field containing the username from the Username Column list.

8. Choose the field containing the password from the Password Column list.

9. Enter the path to the page for the authorized user in the If Login Succeeds, Go To field.

10. If you want the user to proceed to the previously selected link, rather than the page

entered in Step 9, select the Go To Previous URL option.

11. Enter the path to the page for the unauthorized user in the If Login Fails, Go To field.

12. If access levels should be evaluated as part of the authentication:

Select the Restrict Access Based On Username, Password, And Access Level option.

For more information on the Log In User server behavior, see Chapter 22 n

Restrict Access To Page

The Restrict Access To Page server behavior prevents unauthorized users from viewing specific

pages by checking a session variable After it is defined, the server behavior can be copied and

pasted onto another page by using the context menu commands from the Server Behaviors panel.

Requirements: A dynamic page.

To apply the Restrict Access To Page server behavior, follow these steps:

1. From the Server Behaviors panel, click the Add (+) button and choose User

Authentication ➪ Restrict Access To Page The Restrict Access To Page dialog box, shown in Figure 34-14, is displayed.

2. If you don’t want to restrict admission by access levels, be sure that the Restrict Based

On Username And Password option is selected.

3. To set group permissions for the page:

Choose the Restrict Based On Username, Password, And Access Level option.

4. To add new groups to the Select Level(s) list:

Click Define The Define Access Levels dialog box opens.

To delete any levels, choose the level in the list area and click the Remove (–) button.

For more information on the restrict access To page server behavior, see Chapter 22 n

Log Out User

The Log Out User server behavior clears the username session variable established by the Log

In User server behavior and redirects the user to an exit page You can set up the Log Out User

server behavior so that a user selects a link to log out or is automatically logged out when a

par-ticular page, such as one confirming the completion of an order, is viewed.

Requirements: A Log In User server behavior on another page.

To use the Log Out User server behavior, follow these steps:

1. To apply the server behavior to a specific link on the page, select that link.

2. From the Server Behaviors panel, click the Add (+) button and choose User

Authentication ➪ Log Out User The Log Out User dialog box displays (see Figure 34-15).

4. To automatically log out users when the current page is viewed, select the Log Out

When Page Loads option.

5. If you’re using a link as a trigger, enter the path to the destination page in the When

Done, Go To field Alternatively, click the Browse button to locate the file.

Caution

Do not use the When Done, Go To option if you are automatically logging out a user when the page loads If

you do, the user never sees the current page n

6. Click OK when you’re finished.

Cross-Reference

For more information on the Log Out User server behavior, see Chapter 22 n

Check New Username

The Check New Username server behavior verifies that the requested username is not already

in the data source, redirecting the user if it is.

Requirements: An Insert Record server behavior, a form, and appropriate form

elements.

1. From the Server Behaviors panel, click the Add (+) button and choose User Authentication ➪

Check New Username The Check New Username dialog box is displayed, as shown in Figure 34-16.

Figure 34-16

Make sure that a requested username is not already taken by using the Check New Username server

behavior

2. Select the form element that contains the requested username from the Username Field

list If a form element is called USERNAME, Dreamweaver automatically selects that entry.

3. In the If Already Exists, Go To field, enter the path to the file you want a user to see

if the name the user requested is already stored in the data source You can also click Browse to locate the file.

4. Click OK when you’re finished.

For more information on the Check new Username server behavior, see Chapter 22 n

Dynamic elements

With one exception, dynamic elements in Dreamweaver refer to form elements, linked to a data

source field Data-connected form elements are typically used in Web applications that update

records The single exception is Dynamic Text, which is described in the following section

Dynamic Form Elements are covered later.

Dynamic Text

Inserting a Dynamic Text server behavior is the same as dragging a field from a recordset on the

Bindings panel onto the page It’s a matter of individual preference which technique you use;

personally, I find dragging-and-dropping from the Bindings panel much faster and more intuitive

than using the Dynamic Text server behavior.

Requirements: A dynamic page.

To use the Dynamic Text server behavior, follow these steps:

1. Place your cursor on the page where you’d like the dynamic text to appear.

2. From the Server Behaviors panel, choose Dynamic Elements ➪ Dynamic Text The

Dynamic Text dialog box is displayed, as shown in Figure 34-17.

3. If necessary, expand the recordset or other data source to select the desired dynamic data.

4. Choose any necessary server format from the Format list.

Figure 34-17

You can insert dynamic text through either the Server Behaviors panel or the Bindings panel

5. Enter any required adjustments to the dynamic data in the Code field In most

situa-tions, no changes are necessary.

6. Click OK when you’re finished.

Cross-Reference

For more information on adding dynamic text, see Chapter 21 n

Dynamic List/Menu

The Dynamic List/Menu server behavior binds data to one or more aspects of a drop-down list

Dynamic data from a recordset is typically bound to both the values and labels of a list or menu

element; static values and labels may also be combined with the dynamic data In addition, you

have the option to dynamically set the selected value, a feature often used when updating a record.

Requirements: A list/menu form element and a recordset.

To link a drop-down list to dynamic data, follow these steps:

1. Insert a list/menu form element on a dynamic page with a recordset.

2. If you have more than one list/menu on the page, select the one you want to convert.

3. From the Server Behaviors panel, choose Dynamic Form Elements ➪ Dynamic List/

Menu The Dynamic List/Menu dialog box, shown in Figure 34-18, is displayed.

Figure 34-18

Lists give the user a series of items from which to choose

4. Verify that the desired drop-down list is displayed in the Menu list.

5. In the Static Options box, add any nondynamic items you want to the top of the list menu This could be something as simple as a label for the list menu or as complicated

as a full URL with query strings for search pages.

6. Choose the recordset you want to work with from the Options From Recordset list.

7. Choose the field from your data source containing the items that you want displayed to the user from the Labels list.

8. Choose the field from your data source containing the items you want submitted by the

user from the Values list.

9. To preselect an item, enter its value in the Select Value Equal To field or use the ning bolt icon to choose a value from the established data sources.

light-10. Click OK when you’re finished.

Cross-Reference

For more information on the Dynamic List/Menu server behavior, see Chapter 22 n

Dynamic Text Field

Unlike the Dynamic Text server behavior, the Dynamic Text Field server behavior is not just for

show The Dynamic Text Field server behavior is often used for applications that update records

and may be applied to either a text field or text area form element According to the server model

used, the data in the text field can be formatted server-side in a number of ways, such as upper-

or lowercase.

Requirements: A text field or text area form element and a recordset.

To link a text field or text area to dynamic data, follow these steps:

1. Insert a text field into a form on a page with a recordset or other data source It’s a good idea to name the text field and form at this point Although you can always change the names later, naming the elements early on avoids problems later.

2. Select the text field.

3. From the Server Behaviors panel, choose Dynamic Form Elements ➪ Dynamic Text Field.

Caution

Be sure to choose Dynamic Text Field and not Dynamic Text from the Dynamic elements submenu If you

select Dynamic Text while your text field is highlighted, the form element is replaced n

4. In the Dynamic Text Field dialog box that appears (see Figure 34-19), verify that the correct form element was chosen in the Text Field list If necessary, choose a different

You can make a data field editable by connecting it to a Dynamic Text Field

5. Click the Set Value To lightning bolt icon to display the available data sources.

6. Choose a field from the Dynamic Data dialog box.

7. If desired, you can apply a server format to the data by choosing an entry in the

Format list.

8. Click OK to close the Dynamic Data dialog box and, after reviewing your choices, click

OK again to close the Dynamic Text Field dialog box.

Cross-Reference

For more information on the Dynamic Text Field server behavior, see Chapter 22 n

Dynamic CheckBox

Checkboxes provide users with a method of selecting one or more options in a group; a Dynamic

CheckBox server behavior marks any affiliated checkbox as selected if the desired criteria are

met This server behavior is often used in conjunction with a Boolean data field, also known as a

True/False or Yes/No data field.

Requirements: A checkbox form element and a recordset.

To convert a static checkbox to a dynamic one, follow these steps:

1. Select a checkbox in a form on a page with a recordset.

2. From the Server Behaviors panel, choose Dynamic Form Elements ➪ Dynamic

CheckBox The Dynamic CheckBox dialog box appears, as shown in Figure 34-20.

3. Verify that your selected checkbox is correctly named in the CheckBox list.

4. Click the Check If lightning bolt icon to display the available data sources.

5. Choose a field from the Dynamic Data dialog box.

6. If desired, you can apply a server format to the data by choosing an entry in the Format

list Click OK when you’re finished to close the Dynamic Data dialog box.

Checkboxes can depict whether a particular field of a recordset is True or False

7. Enter the value expected for a selected checkbox in the Equal To field This value is data source–dependent For many data sources, 1 is used to represent True; for others, a -1

is used When working with Yes/No fields from Access databases, enter True; be sure to

capitalize the word, because lowercase does not work properly.

8. Click OK when you’re finished.

Cross-Reference

For more information on the Dynamic CheckBox server behavior, see Chapter 22 n

Dynamic Radio Buttons

Radio buttons are employed in a form when the designer wants the user to make an exclusive

choice among a set number of options As with the Dynamic CheckBox server behavior, the

Dynamic Radio Buttons server behavior is used to mark a particular element as selected when

the defined criteria are met.

Requirements: Two or more radio button form elements and a recordset.

To link radio buttons to dynamic data, follow these steps:

1. Select a group of radio buttons on a dynamic page with an available data source.

2. From the Server Behaviors panel, choose Dynamic Form Elements ➪ Dynamic Radio

Buttons The Dynamic Radio Buttons dialog box appears, as shown in Figure 34-21.

3. Verify that your selected form element is displayed in the Radio Button Group list.

4. In the Radio Button Values area, choose the first entry shown and, if necessary, change the Value field to reflect the expected data.

5. Repeat Step 4 for every radio button in the group.

6. Click the Select Value Equal To lightning-bolt icon to display the available data sources.