Testing server behaviors – Adobe Dreamweaver CC 2014 v.13 User Manual
Page 554
Error checking 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 run-time functions and global variables in a page. One convention is to use your initials. Never use
the MM_ prefix, as it is reserved for Dreamweaver use only. Dreamweaver 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.
Testing server behaviors
The Dreamweaver 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 run-time 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.
547