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.
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.