Dreamweaver and the ColdFusion MX Workflow

Recreate the visual-development workflow that produced many mid-2000s ColdFusion applications, then learn how to review and improve the generated code.

The Mid-2000s ColdFusion Development Experience

Dreamweaver MX and Dreamweaver 8 could define a ColdFusion site, connect to a testing server, browse datasources through RDS, create recordsets, and generate server-side behaviors. That workflow helped designers and developers assemble database-backed pages quickly.

RDS is a privileged development service. Use it only inside an isolated lab. Never expose it to the internet or leave it enabled on a production server.

Typical Site Definition

SettingExample Lab ValuePurpose
Local root folderC:\Sites\support-tracker\Working copy edited in Dreamweaver.
Remote folder\cfmx-server\wwwroot\support-tracker\Destination used for lab deployment.
Testing server modelColdFusionTells Dreamweaver which server behaviors and code model to use.
Testing server accessLocal/network or FTPHow files reach the server that executes CFML.
URL prefixhttp://cfmx-server/support-tracker/Maps the project folder to a browser URL.

Panels Commonly Used

Databases

Browse ColdFusion datasources, tables, columns, and stored procedures through the testing server.

Bindings

Expose query columns, form values, URL values, session variables, and component results for insertion into a page.

Server Behaviors

Generate recordsets, repeat regions, dynamic text, insert/update/delete forms, and navigation.

Files

Manage local and remote copies, synchronize files, and use check-in/check-out features on team projects.

A Generated Recordset Pattern

<cfquery name="rsCustomers" datasource="support_portal">
SELECT id, name, email
FROM customers
ORDER BY name
</cfquery>

<cfoutput query="rsCustomers">
    #name#<br>
</cfoutput>

This is recognizable and easy to learn, but a maintainer should improve output encoding, formatting, selected columns, error behavior, and any dynamic SQL values.

Generated Dynamic Filtering

Server behaviors sometimes generated SQL by inserting request variables directly into the statement. Treat generated code as a starting point, not proof that the code is secure.

<!--- Unsafe legacy pattern --->
<cfquery name="rsCustomer" datasource="support_portal">
SELECT id, name, email
FROM customers
WHERE id = #url.id#
</cfquery>

<!--- Safer MX-compatible version --->
<cfquery name="rsCustomer" datasource="support_portal">
SELECT id, name, email
FROM customers
WHERE id = <cfqueryparam value="#Val(url.id)#" cfsqltype="cf_sql_integer">
</cfquery>

Design View and Code View

Design View was useful for page layout, but generated or nested CFML could be represented imperfectly. Use Code View to understand the actual request flow, tag nesting, query scope, and output expressions.

Dreamweaver Templates

Dreamweaver template files could define editable and locked regions across a site. They are different from ColdFusion templates: a Dreamweaver template is a development-time page-management feature, while a .cfm file executes on the server.

Practical Retro Exercise

  1. Define a ColdFusion site and testing server in the isolated lab.
  2. Create the support_portal datasource in ColdFusion Administrator.
  3. Use Dreamweaver to create a customer recordset and repeat region.
  4. Inspect the generated CFML in Code View.
  5. Add cfqueryparam to every dynamic SQL value.
  6. Add HTMLEditFormat() when displaying customer-controlled text.
  7. Move the query into a tag-based service CFC.
  8. Compare the generated page with the hand-structured version.

What the Workflow Teaches

  • How rapid application development tools shaped legacy code structure
  • Why queries and presentation often appear in the same template
  • Where implicit dependencies and generated variable names come from
  • Why visual tooling does not replace code review or security review
  • How to preserve the historical workflow while improving the resulting CFML