Workshop 2: Inserting Dynamically Determined Images

' ' ' ' Workshop #2: Inserting Dynamically Determined Images"-->

Workshop #2: Inserting Dynamically Determined Images

This behavior comes from one of my favorite database tricks: using an ID field from a database record to construct names and pathnames of images to insert in documents. An online catalog, for instance, might give each inventory item a unique ID such as CW-11 . The manufacturer of that item might have the unique ID CW . Given those IDs, if I save a picture of the product as CW-11.jpg, and store it in a folder with all my other images, I can construct image paths for my documents without having to add an extra database field to store the image name or path . Although it's certainly possible to use the dynamic attributes available in Dreamweaver to accomplish this same thing, there's a lot less typing and thinking involved if it can be packaged up into a nice neat server behavior.

Task 1: Create the code to insert

This particular task highlights the limitations that the Dreamweaver API puts on syntax for server markup. One way to code the dynamic image tag is as a series of dynamic attributes, like this:

 <img src="Images/" + <% Stuff.Fields.Item("itemID").Value %> + ".jpg"  alt="<%Stuff.Fields.Item("itemID").Value%>"> 

But this would require either inserting one code block that consists of multiple tags, or multiple code blocks of incomplete tags, and the SBB doesn't allow for these. But we can write the code like this:

 <%  var folderpath="images/";  var basename=Inventory.Fields.Item("itemID").Value;  var fileExt=".jpg";  var altLabel=Inventory.Fields.Item("itemname").Value;  %>  <img<%=' src="'+folderpath+basename+fileExt+'" alt="'+altLabel+'"' %>> 

Because this code consists of two complete tags (the <% %> pair and the <img> tag itself), it can be inserted as a two-block server behavior. So that's the code we'll choose to insert. (Again, test it if you're not sure what it's doing, or not sure that you have it coded correctly.)

Task 2: Create the behavior with hard-coded values

Repeating the procedure from the previous workshop, choose the New Server Behavior command and create a behavior called Dynamic Image. Create two code blocks for it, based on the code shown in Task 1, and test it out to make sure it works. Figure 9.19 shows the SBB dialog box with code block entries completed.

Figure 9.19. The SBB dialog box for the Dynamic Image server behavior.

Task 3: Replace hard-coded values with parameters

This also is the same as in the previous workshop. Be careful, though, with your quotes! There are a lot of them to watch out for in this bit of concatenating. The final code for your second code block won't have any parameters added to it. The code for your first code block should have the following parameters inserted in place of hardcoded entries (parameters are shown in bold):

 <%  var folderpath="  @@folderpathParam@@  ";  var basename=  @@rsSrcParam@@  .Fields.Item("  @@fieldSrcParam@@  ").Value;  var fileExt="  @@fileExtParam@@  ";  var altLabel=  @@rsAltParam@@  .Fields.Item("  @@fieldAltParam@@  ").Value;  %> 

When you're done adding the parameters, make sure you set the dialog box up so that the proper input elements are used for each one. As before, you'll have a mixture of text fields, Recordset menus, and Recordset Field menus . Figure 9.20 shows the proper assignment of element types.

Figure 9.20. Setting up the Dynamic Image behavior dialog box in the SBB.

Task 4: Refine as needed

As in Workshop #1, use the Advanced controls in the SBB dialog box to determine how the behavior appears in the Server Behaviors panel and to determine which code block is selected when the behavior is chosen in the panel's list of applied behaviors. Open Dynamic Image.htm (in Configuration/Server Behaviors/ASP_JS) and tweak the form layout as desired, relabeling the form elements for user -friendliness. Figure 9.21 shows what the refined dialog box might look like.

Figure 9.21. The Dynamic Image dialog box with a slightly revised layout.

Task 5: Add error-checking

Here's where you need to dip a little further into the extension files. What if the user forgets to add the trailing / after the folder name? What if the user specifies a .jpg or .gif file extension, but forgets the opening .? This sort of validation and fixingup is a nicety of good interface design. Adding it means revising the applyServerBehavior() function.

1. Open the Dynamic Image.htm file in your text editor and find its applyServerBehavior() function. You should see the following code:

    1 function applyServerBehavior(sbObj) {  2   var paramObj = new Object();  3   var errStr = "";  4   if (!errStr)  5     errStr = _folderpathParam.applyServerBehavior(sbObj, paramObj);  6   if (!errStr)  7     errStr = _rsSrcParam.applyServerBehavior(sbObj, paramObj);  8   if (!errStr)  9     errStr = _fieldSrcParam.applyServerBehavior(sbObj, paramObj);  10  if (!errStr)  11    errStr = _fileExtParam.applyServerBehavior(sbObj, paramObj);  12  if (!errStr)  13    errStr = _rsAltParam.applyServerBehavior(sbObj, paramObj);  14  if (!errStr)  15    errStr = _fieldAltParam.applyServerBehavior(sbObj, paramObj);  16  if (!errStr) {  17    fixUpSelection(dw.getDocumentDOM(), true, true);  18    applySB(paramObj, sbObj)  19  }  20  return errStr;  21 } 

   What's happening here? Before the behavior can be inserted, all data must be collected into an object representing the behavior's main code sbObj and an object representing the user-defined parameters paramObj . Those two objects are then passed to the applySB() helper function. In order to create the parameter object, each of the dialog box's input elements has been defined as an instance of a custom class, and a class method is being called that retrieves the user's input and turns it into a property of the paramObj object. Assuming you named your parameters the same as in the example code, your paramObj will end up having the following properties assigned to it:

    paramObj.folderpathParam;  paramObj.rsSrcParam;  paramObj.fieldSrcParam;  paramObj.fileExtParam;  paramObj.rsAltParam;  paramObj.fieldAltParam; 

   Can you see where these names came from? By the time applySB() is called at the bottom of the main function, all of these properties will have data in them. You can use those properties for error-checking.

2. Add the following lines of code directly above the applySB() function call (new code is in bold):

    1  function applyServerBehavior(sbObj) {  etc   18 //begin error-checking   19 var extString=paramObj.fileExtParam;   20 if (extString.search(/\./)<0) {   21    paramObj.fileExtParam="."+extString;   22    }//end if   23 var folderString=paramObj.folderpathParam;   24 if (folderString.search(/\/$/)<0) {   25    paramObj.folderpathParam+="/";   26    }//end if   27 //end error-checking  28    applySB(paramObj, sbObj)  29  }  30  return errStr;  31 } 

   What is this code doing? Lines 1922 collect the value the user has entered as a file extension ( fileExtParam ), and use a conditional to determine if a . needs to be added at the beginning. Lines 2326 collect the folder path ( folderPathParam ) and use a conditional to determine if a / needs to be added at the end.

3. When your error-checking is in place, try out your new behavior. Can you enter parameters in the Dynamic Image dialog box that will break it? If so, come back to the applyServerBehavior() function and expand your error-checking as needed. Keep tinkering until you have a nice, robust server behavior.

That's the end of the workshop. Is it the end of what you can do with server behaviors? Certainly not! You can go much further than this in customizing the applyServerBehavior() and other API functions, though it's a difficult undertaking because the server behavior API is built from so many diverse, interrelated modules. But as long as you don't interfere with the main workings of the behavior, as set up by the SBB, you can still add data preparation and error-checking to fine-tune your behaviors.