These are notes from the Design Patterns and ColdFusion presentation by Sean Corfield on 12/13/07.

Design patterns are basically common solutions to recurring problems. Using a pattern provides a common vocabulary between developers. If you say, “I’m using a Remote Facade”, someone else will know what you’re talking about without any further explanation.

What makes up a pattern? (a) A name, to provide a common vocabulary between developers. (b) A recurring problem; typically there are “forces”, or circumstances in the coding situation, that will lead you to use the pattern. (c) The solution, or template for solving the problem. Note that a pattern doesn’t have an exact, proper way to be executed. It is indeed just a guide, or template. (d) Consequences: Every pattern has its pros and cons.

Common Problems and Design Patterns

1. Problem: Duplicate site content at top and bottom of site.
   Pattern Name: Composite View
   Solution: Include a header and footer that has this duplicated content.
2. Problem: Need an instance of an object that is accessible everywhere in an application.
   Pattern Name: Singleton
   Solution: Create it at application startup and put it in application scope.
   Trade offs: Initialization is in one place (+). Easy access to objects app-wide (+). But now your code is very dependent on that application scope, which breaks encapsulation (-).
3. Problem: Several components make up a particular functionality, but you don’t want to expose all of that complexity to the calling code, especially in case I want to change how I implement it.
   Pattern Name: Facade
   Solution: Create a new component that has a nice, simple, high-level API. Client code calls it, and it calls all the complex components under the hood.
   Trade offs: App code no longer needs to no about all of the complex internals (+). However, there will be redundancy of methods between the API and the underlying code, which is more maintenance and more coding (-).
4. Problem: I need some standardized code that runs on every request of the application, perhaps security checks.
   Pattern Name: Front Controller
   Solution: Make all requests go through a common piece of code, and have that code apply the logic before/after processing the actual request. i.e. index.cfm?page=myaction. Everything routes through index.cfm.
   Trade offs: Full control over every request; can easily add add’l functionality (+). All URLs look similar (+/-). The control page (index.cfm) can get complicated (-).

Recognize that patterns are NOT code. Any example code for a pattern is just that: An example. Design patterns can apply to any language and typically can be used in the design phase of an app. Some patterns are language-specific. Do patterns have an object-oriented bias? Well, yes. Most design patterns are focused on OO design. But design patterns in general do not have to be OO-specific. It just tends to be OO people who are considering design patterns.

Ruby Patterns for Consideration

1. Active Record pattern for managing persistence of objects. An object knows how to save/get itself with a database.
2. Dynamic finder methods. By virtue of the method name, the functionality can be figured out. This is done with a method that runs when the called method doesn’t exist (”method_missing”). That method can than act on the method that was called based on its name. ColdFusion can do this with the onMissingMethod() method of a CFC.

Patterns and interfaces. Interfaces are not needed but are useful as a descriptive tool in explaining pattern implementations. ColdFusion 8 introduced <cfinterface>. Alternatively, you could use duck typing.

Design Patterns from Gang of Four

• Creational Patterns
  • Abstract Factory, Builder, Factory Method, Prototype, Singleton
• Structural Patterns
  • Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
• Behavioral Patterns
  • Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor

To learn patterns, you can observe frameworks, which often implement multiple patterns: Front Controller, MVC, Identity Maps, Context Objects, etc.

Thanks for the great presentation, Sean.

These are notes from John Paul Ashenfelter’s presentation on 12/13/07 regarding pragmatic development. The entire discussion is done with open source tools and can be set up in an afternoon.

Build it CRISP: Complete, Repeatable, Informative, Schedulable, Portable. Building is taking all the pieces and creating the final product. All source code should be in a repository; there’s no other way to do it. Perhaps you’ll want continuous development: Every commit, it is redeployed. This especially makes sense for the QA server.

Source control is a must. Subversion is the popular source control option for now.

Automation is an important factor for building. Shell scripts can get the job done (although Windows shell isn’t so good), but tools like make, rake, and Ant seem to be better for this kind of thing. Considering Ant’s popularity in the Java world–and ColdFusion’s connection to Java–it often is the automation tool of choice. It’s easy to install, widely used.

Testing is another important factor in the process. CfcUnit is “pretty darn solid”. Functional testing tools like Selenium and Canoo WebTest are useful too. Depending on your deployment, load-testing tools like Grinder may be useful too.  However, load-testing may sometimes be frustrating to set up. Worry more about your unit and functional tests.

Selenium is useful for any of the testing of your application that is repetitious.  The nice thing is that you don’t even have to know how to write Selenium tests. With the IDE, you can record your tests by walking through the application, and then the Selenium test will be generated.  Flex and Flash are problematic, but other elements of web pages work great, including AJAX code.

Using Ant. When using Ant, dbUnit can be extremely useful to also reset your database to a certain condition. Not good for HUGE amounts of data, though.  Use SvnAnt v1.1 (it doesn’t use JavaHL). To learn how to use ant, try the Ant Manual. Also try looking at well-annotated ant scripts written by other people.
Charlie mentioned an excellent blog post with lots of resources for Subversion from a ColdFusion developer’s perspective.

A very decent presentation. Thanks, John.

I was working with an app that would take an LDAP query from <cfldap> and do a bunch of processing against it. As it turns out, the LDAP query was targeted on an OU that wasn't grabbing all of the accounts it needed to process. There was a sibling OU that also needed to be included in the results.

I already had scope="SUBTREE" in the <cfldap> call, so I could've just set the context of the LDAP query to the parent of both OU's, but then it would grab a whole bunch of accounts that were in OU's that shouldn't be included in the processing. I could have restricted what was being pulled with a filter, but I already had several filters in the LDAP call and I didn't want to complicate that any further.

Well, think simpler then. What about just wrapping the LDAP call and its processing with a <cfloop>, executing against the different OU's each time? If the processing were simpler, that could've worked, but there is report generation and other stuff going on, and really all the accounts needed to be processed in one sweep.

There is still a simple solution: Query of Queries. Perform each LDAP call separately, then join the results together with a simple UNION statement.

Now all the processing that occurs in my <cfoutput> tags that process the LDAP results will all happen in one sweep, with very few lines of code being altered, and none of my processing code had to be altered.

I simplified the code for this post, but in the app, the OU's are defined by a config file. So, the <cfldap> calls are executed in a loop, and then the SQL with the union statement is also generated by a loop based on the setting in the config file. So, at a later time, more OU's could be added with no additional coding required.

The following are notes from the XML 101 class at Adobe MAX 2007. I'm skipping over the extremely basic XML principles and covering the more interesting stuff.

When use XML nodes over attributes? Attributes are good for set, simple values. If you have complex values, multiples of a particular entry, or you want more extensibility, use nodes for XML.

The presenter demonstrated using DTDs over XML Schemas. The DTDs use a very specific grammar that is not even XML-ish. It's kind of yesterday's XML descriptor. Nowadays, better to use XML Schemas, which are actually XML defining XML. Both are ugly in my opinion, and XML Schemas are more verbose (as XML usually is), but you might as well go with the latest, most accepted convention, which is the XML Schema approach.

By using DTDs and XML Schemas, apps can be cognizant of the structure of your XML language. Even from a developer's viewpoint, this can be useful when editing XML within an IDE.

The real fun part is formatting the XML with XSL (eXtensible Stylesheet Language). Supports loops, conditional logic, and other processing. Think of it as CSS on steroids, for XML. With XSL, you can transform XML to HTML, or PDF, or other fun stuff.

XPath is the heart of XSL processing. Allows you to traverse the XML document and find exactly what you're looking for, whether it's a particular node or looping over a group of items (xsl:for-each).

You CAN send the XML and XSL to the client and have the transformation be done client-side. All modern browsers include the XML/XSL engine. But generally it is wiser to do the transformation on the server side.

In my opinion, this approach lowers the value of XSL, because I can just as easily write some CF that will act on the XML. Yeah, I can write numerous XSLs for different presentations (text-only, XHTML, PDF, etc), but I'd have to do the effort of writing different XSL docs for that, when I could just as easily write different CF processors that accomplish the same thing. Unless you are working with a huge number of documents of varying types, XSL may not provide a large enough of an advantage for a language like CF that so easily manipulates XML.

The final step is grabbing XML with Ajax (such as Spry) that will populate document spaces (tables, divs, etc) with the XML data very easily as well. Again, this approach is similar to the CF approach, but with a more JavaScript-heavy slant.