These are notes for a presentation on Savvy, the content management system, by Joshua Cyr.

For setup, there is a cfm page that has numerous CFSETs that you have to set. After that, everything is basically good to go. It will create the database in the DSN you provide it, by simply running an install script by calling a cfm page.

First thing you’ll have to do when you login: Set up some templates for your site. In CFEclipse, he took a normal HTML page with content, and just started editing Savvy tags. He replaced the <title> with a header object, some menu navigation with a nav object, basic content with a content object. What about when you alter a template? There is an option to rebuild pages (or entire site) for when a template is changed.

He showed that an object can be shared. This way, anytime an object with that name appears on any page, changes to that object will be reflected on all of the pages.

Creating pages and directories, actual physical files and directories are indeed saved. This is handy for apps that do traffic analysis. Sometimes they sputter on pages that have a front controller for pages (index.cfm?page=MyPage).

When you create a page, you then can view each content area in the new page. Just click on it and you can edit that particular content area. The editing mechanism is pretty typical: A WYSIWYG editor, decent picture management. You can adjust settings so that the WYSIWYG editor will look exactly like you want it. Handling links is pretty simple: Can pull up a screen similar to picking a picture, except for pages. When you start typing a page name, it has auto-suggest to help. Note that the link management is very basic: It helps you create a hard link in the content, and nothing is done to warn you if you will break links when you change a page’s name or location (or delete it).

When it comes time to publish, you can publish an object at a time, or the whole page. Publishing can be scheduled, and expiration is available as well. Additionally, it supports workflow where the user will not have publishing rights, so instead he can request publishing, and then a person with that permission will do the publishing. Savvy does not have sophisticated workflow management, however. It keeps the process simplified. History of items is recorded and can be viewed. History by object/page or by user.

When managing users, you not only can supply exact permissions of what a user can do, but also can do groups that users belong to. Then perms are assigned based on their group.

Now, when you have CF in you template page, it doesn’t work like you’d expect, when a new page is created from a template, it will effectively paste in the results of your CF, not actually render the CF on the page. Thus, welcome to their custom code object. It effectively acts like a CFINCLUDE for your pages.

Savvy plays nice with other CF applications. He did not demo or speak on this any further, though.

Thanks, Joshua.

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.

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.