The Wandering Fishbowl

Hating Online Only Help in Creative Suite

2009-06-02T10:27:00.003-04:00

Perhaps I'm just getting old and crusty, or perhaps it's just lack of sleep, but I'm really not liking the way the current Creative Suite 4 products go online for help. Seriously, does this content really change so much that having offline help isn't useful? Last time I checked the Dreamweaver documentation hasn't changed all that much since Mx2004.
First of all, fat lot of good it does me when I'm on a laptop on the train. Even if I had a cellular card in my machine, which I don't, would I really want to be wasting my monthly bandwidth allotment, looking up a tag or function that I don't use frequently. Not to mention, that much of my ride is underground and out of cellular range.
My second beef is that Dreamweaver CS 4 help (F1) defaults to the Dreamweaver Support Center rather than the Dreamweaver Documentation. Sure, the link for documentation is there on the right, but it is quite hard to spot. I realize that you can change the default behavior back to point to the documentation, but again, it's not easy to find.
Most likely I'll just download the PDF versions and think very carefully before upgrading in the future. It seems to me that this is yet another case of just because you can do something, doesn't mean you should.
In any event, that's my rant for the day.

Microsoft.com to use CFML?

2009-04-01T10:42:00.004-04:00

Sources within Microsoft's web division revealed late last night that Microsoft is seriously considering microsoft.com to ColdFusion. Said our source, "Let's face it, if we switch to ColdFusion we can get by on 3/4 of our current staff. These days, that's a big consideration." While politics is often blamed for making strange bedfellows, it appears that adversity can sometimes do the trick as well. Should this decision come to pass, expect the announcement within days.

Broom Development

2009-03-10T10:05:00.002-04:00

I was listening to January's Defining Moments on my way to work this morning and was introduced to the concept of broom theology by Dr. Michael Simone. The concept comes from a job at a small trucking company that Dr. Simone once worked for.

On days when work was slow, the old guy in the warehouse would say, "If you have nothing to do, pick up a broom and start sweeping the warehouse."

In churches, similar situations arise, and broom theology says, "Look around for someone who needs help or somewhere you can help." In many ways the web development world is quite different than the church world, but I think we can borrow this concept of broom theology and refactor it to become broom development.

Broom development states:
When you hit those lull times that occur even in the busiest of development shops, use the time productively.

See if anyone on your team could use some help.
Pay down some of your team's technical debt.
If all else fails, there's always documentation or learning new skills.

So, the next time you find yourself in that lull and are tempted to find out how "The Woz" did on this weeks Dancing with the Stars, I encourage you to consider practicing some broom development. You might just learn something about yourself, a co-worker, or your craft.

Welcome Back From the Dark Side

2008-11-06T10:51:00.002-05:00

I'd like to take this, slightly belated¹, opportunity both to welcome David Patricola to Jefferson, as well as welcome him back from the dark side². David has a history of working with ColdFusion, however, in recent years he's been working in the PHP world. Fortunately now we have him back in the CF community.

¹ David began with us sometime in October, though I'm just starting to get my head back above water now.

² Calling PHP the dark side is not intended as an attack on PHP developers. We in the ColdFusion community mourn for our PHP brethren who must toil endlessly with tasks that we perform in minutes.

CF Developer needed in Philadelphia, PA

2008-06-27T09:04:00.005-04:00

Thomas Jefferson University^* is currently looking for an Intermediate to Advanced level ColdFusion developer with strong design and layout skills. Flash/Flex skills and knowledge of Contribute a plus.

We are a small team that maintains TJU's internet and intranet web presence. In addition we do small to medium sized ColdFusion applications for various departments. For many of our projects we utilize Model-Glue. We provide complete service from design to database work. We are currently in the middle of a re-branding effort, our new look can be seen on our Electronic Medical Records site.

^*Note: Our employment page is due to be upgraded in the very near future. As such I'm providing a basic link that will be valid before and after the upgrade.

Odd LDAP Calls from Contribute Publishing Services

2008-06-06T14:33:00.003-04:00

We've recently updated our LDAP and noticed a slowdown on authenticating through Contribute Publishing services. Upon looking into the issue, we determined that Contribute Publishing Server was sending what to us appears to be a malformed LDAP filter. Before I call Adobe support, I thought I'd check to see if anybody else has encountered this issues. Our setup looks something like this. (I've changed the actual data for security reasons.)

Our user search tab has CN, Mail and UID Defined along with a basic filter. (!(status=I)) Our Group tab is blank as our LDAP does not contain groups. With this setup, when attempting to authenticate user lm1000, CPS send the following filter to the LDAP.

(&(!(status=I))(|(uid=lm1000)(=lm1000)))

When I run this filter in an LDAP browser I see the same slow behavior, however when I remove (=lm1000) the LDAP responds immediately. Has anyone seen this behavior before? Am I not configuring something properly, because to the best of my knoledge, an LDAP filter must contain an attribute name to look for a value in.

Update: It turns out that adding the UID field in the group tab resolves this issue.

Future ColdFusion Features

2008-04-01T14:36:00.004-04:00

During the recent Adobe Developer Week, I somehow found myself in a private session showing off some high end features that are being worked on for ColdFusion 9. Now, I'm sure that those invited all agreed not to disclose any information that was being presented, but since I ended up there uninvited, I thought I'd share what I saw. They began the session by explaining that what with all of the great new features released in ColdFusion 7 & 8, ColdFusion is in danger of losing one of it's sets of core users. They call this group the Common Laymen and Office Dwellers or CLODs for short. In order to address the concerns of their CLOD constituency that ColdFusion is getting too complex, they've decided to add a new tag.

That simple tag produced the following site...

From what I can tell, the tag does a yellow pages search on the name and location to find specific address, phone and hours, then goes out and finds appropriate graphics, before finally generating the site. My assumption is that the site is then cached somewhere, since I would assume that those searches would run a bit slow under load.

I for one am very exited about the efforts Adobe is going to in order to make the life of the average CLOD better. Oh, and if anyone asks, you didn't hear this from me.

Testing is hard work!

2008-02-15T16:03:00.000-05:00

I recently found myself in the beta test group for Tunnels of Doom Reboot. My initial thought was that this would be easy. After all, I do write code for a living. I regularly test my code as well as my colleagues' code. I've spent countless hours of my life playing the original; I know it inside and out. How hard could this be?

Enter a world of fantasy where your instincts and imagination determine your chances of survival. Your journey is about to begin—Prepare yourself.
–Tunnels of Doom Manual

When the beta became available to the testers, I downloaded it, fired it up, and quite frankly had a ball. That day I submitted my first 'bug report' which consisted of a 'bug' that I could not reproduce as well as a handful of usability suggestions. Shortly after that the first status report came out, with a number of reported bugs list, most of which I had seen, but not thought to mention.

My big problem was that I was approaching it like a gamer and not like a tester. While I did not have access to the design spec to confirm behavior against like I normally do, several of the bugs that I failed to report, were pretty obvious. For my part, once I realized my mistake, I fired the application back up and have since delivered the type of bug reports that I want to see when folks are testing my code.

The thing is as web developers we are all very aware of the limitations of web-based applications, and it is easy for us to ignore things that are not easy to fix. We cannot, however, let ourselves become complacent. With the help of newer technologies such as Flex, we are in a position to overcome many of the historical limitations of web-based applications. The challenge is weilding these new technologies appropriately, and freeing ourselves from the limitations and thinking of the past.

Should we extend CF Objects with java APIs?

2008-01-31T13:06:00.000-05:00

There have been a couple of recent posts regarding extending ColdFusion data types using the underlying java APIs.

ColdFusion array is actually an implementation of java list (java.util.List). So all the list methods are actually available for Array. CF provides most of the list functionality using Array functions but there are few things possible with java list which you can not do directly with CF functions.

For example, you can use java API to search an array to determine the position of a given search criteria.

<cfset myArray = listToArray('vanilla,chocolate,strawberry') />
<cfif myArray.contains('strawberry')>
<cfset strawberryIndex = myArray.indexof('strawberry') + 1 />
</cfif>
<cfoutput>#myArray[strawberryIndex]#</cfoutput>

Note the adjustment that I've made to account for java arrays starting at 0. Russ Johnson, Rupesh Kumar and Adrian Moreno go into how to do this in more detail.

It's really quite cool that we can do this sort of thing, but should we? One of the great strengths of ColdFusion is its backwards compatibility. I have code, written for ColdFusion 4.5, that's been running untouched for 6 or 7 years. For those keeping count that's about 5 major releases ago. Adobe/Macromedia/Allaire has been great over the years about letting us know what's changed with various versions of ColdFusion. What happens if a future version of ColdFusion ends up breaking this functionality? We certainly can't expect Adobe to keep us informed when one of their changes breaks undocumented features of the product.

Perhaps it's because I'm in the middle of planning a ColdFusion 8 migration, but for my money maintainability nine times out of ten outweighs the short term gain of using these features. That's not to say that I'll never use this knowledge, but that I'll think very carefully about the possible consequences and benefits before doing so.

Coping with Change

2008-01-17T16:00:00.000-05:00

We interrupt our (semi) regular blog entry to bring you some thoughts on change. I mentioned that I was dealing with a reorganization a few months back. Before that I had the good fortune of being in a totally stable environment for 6 years, which if you've been at this professionally for any length of time, you know is practically unheard of in business. As a result some of our younger staff members are having a bit of trouble coping with the changes that a reorganization invariably brings.

Ch-ch-changes
Just gonna have to be a different man
Time may change me
But I can't trace time
- David Bowie

For me the change has meant watching new folks move in while most of my co-workers moved out, then moving down to be with most of my old co-workers, knowing that the changes are not complete and that I may find myself moving back or someplace completely different at any given time. For those of you who are fairly new to the business world, change is to be expected. Keep your head down, watch your back, work hard, don't take it personally, and you'll come through it fine. For those of us who've seen change before, don't forget to encourage and comfort your co-workers who have not been through it before. (at least the one's you want to keep.)

IDE Survey Relevance

2008-01-07T14:16:00.000-05:00

As I'm sure you are already aware, there is a ColdFusion IDE survey out right now.

Tired of Dreamweaver/CFEclipse/Homesite/CFStudio/Notepad? Do you wish they did more or there was something better out there altogether? Do you want Adobe to provide it? Help us help you! We want to hear your thoughts about how we can best support you and your development in ColdFusion!

Of course I want better tools! Who doesn't? The fact of the matter is that there never will be the perfect IDE for all situations. We each pick the tool that best fits us, but let's face it, the right IDE for me may not be the right IDE for you. If I'm not careful, this could degrade into a full fledged rant.

The point I'm trying to make here is that I question how useful a 7 question (26 if you consider the parts of question 5 individually) really going to be to the ColdFusion team. It seems to me that it would make sense to start with a simple survey to determine if the ColdFusion community is interested in a new ColdFusion IDE from Adobe, and what the community thinks it should cost (not that people will necessarily pay what they say they think something should be worth, but that's besides the point). Once they decide to proceed, then a second, much more detailed survey could be conducted as part of a larger requirements analysis. From there they could then narrow down the features that they intend to implement, and proceed with a standard development cycle.

Of course, I did fill the survey out, but I do have to question it's relevance. Oops, guess I did end up with a full fledged rant.

FCKeditor can meet your rich text needs.

2007-12-28T11:08:00.000-05:00

I realize that FCKeditor is bundled with ColdFusion 8, but those of us running ColdFusion 7, or PHP, or any number of other languages, can also take advantage of this flexibly licensed, powerful, and thanks to included hooks and samples, easy to integrate rich text editor. I should say up front, that I am in no way affiliated with the FCKeditor project, but am simply a satisfied user.

For users of ColdFusion 6 and above it can be as simple as downloading and unzipping the editor, and then calling the included fckeditor.cfc like this:


<cfset editorInstance = createObject('component', 'path.to.fckeditorcfc') />
<cfset editorInstance.instanceName = "formFieldName" />
<cfset editorInstance.basePath = "/path/to/fckeditor/" />
<cfset editorInstance.Create() />

Note: This screenshot does not represent the default button set.

On the back end, the HTML generated by the editor simply comes through as a form field value using the instanceName that you set, making it dead simple to enhance existing forms.

If you've been unsure how to implement rich text editors, or have been struggling with one that doesn't quite meet your needs, I urge you to give FCKeditor a try.

Think More, Code Less

2007-11-12T11:55:00.000-05:00

This is the first in what I hope will become a series of posts aimed at beginner and intermediate level web developers. I see it as a venue to share some of the lessons I've learned, and what's worked for me, rather than a definitive development guide.

I've had a quote taped to my door for a few years now, that struck me when I first read it, but didn't really take on any serious meaning until recently.

Code that only you can understand does not make you an advanced coder; code that your grandmother can understand does!
Jeremy Brown - Macromedia Flash MX 2004 ActionScript 2.0 Dictionary

When I initially saw this quote, I took it to mean that I needed to make sure that I wrote clearly and comment things accurately, so that in the future it would be easy to figure out what I had done. Since that time I have slowly come to realize that it means that I need to take the time to think strategically about the code I'm going to write, so that I can keep it as simple and small as possible. All other things being equal, a small amount of code is inherently easier to understand than a large amount of code.

Successfully keeping your codebase as small as possible requires planning up front. Don't get me wrong here, I'm in no way suggesting that one shouldn't prototype. What I'm suggesting is that the prototype should not become the beginning of your codebase. At first glance this might appear to increase your development time, and while this may or may not be true, if done right you will more than make up for this time with ease of maintenance. The key here is doing enough planning to help you steer away from major pitfalls, without boxing yourself in. Your plans, along with any prototypes, should be treated like an artists sketches. They help guide you and prepare you for the final work.

Finally, keep in mind that common sense can be your best asset. I tend to work with Model-Glue for my medium to large scale projects, but I will really think it out before I use it for a small project. It's a question of whether or not the added complexity of a framework will make it easier or more difficult to maintain my project. The answer typically depends on how much I foresee the project growing/changing, and the difficulty of migrating into a framework later if needed. I've even been known to forego CFCs in favor of old school ColdFusion 4 style programming on real simple projects (Typically only if we're talking 1-2 hours of effort and 75 lines of code or less). The point is that you shouldn't be afraid to deviate from "best practices" when the situation warrants, however, when you do it is vitally important to make good notes of what you've done and why you've done it so that the next person that comes along to touch that code, understands what's been done and why.

Coding with the Stars

2007-10-17T16:11:00.000-04:00

Bear with me for a bit, this post is actually on topic. Ok, I'll admit it; my wife has me watching Dancing with the Stars. We've watched for a few seasons now, and I must say that this season's stars are improving much faster than in previous seasons. While a lot of the credit goes to the hard work that the stars themselves are putting in, I think a good deal of the credit goes to their professional partners who are all really taking advantage of their star's strengths, while minimizing their weaknesses.

I've noticed that I've received a similar benefit in the two or so years that I've been actively reading blog entries, participating in comments, and ultimately blogging myself. I haven't blogged much lately, and shockingly enough it has little to do with the standard lame excuses. The fact of the matter is that I've composed several blog entries recently only to read what's out there before I post and discover that it's the hot topic of the day around the ColdFusion community. Unfortunately each of these times, I've had nothing significant to add to the discussion, so I've ended up shelving those posts.

My initial thought was, "Wow, I'm dialed into the communal brain. That means I've made it." Upon further review, I realize that it's probably more that by reading posts from people in the community, I've be shamelessly sponging as much knowledge from some of the world's best CF developers as I can. The fact that I'm starting to think about the same things as they do, means that I've finally digested much of what I've read, much like the stars and their professional dance partners. While I don't know that I actually want to dance with any of you, I'll save the dancing for my wife, I look forward to continuing to learn and share what I learn.

For any ColdFusion newbie who might happen on by, I implore you to take full advantage of the CF community. Read blogs, ask questions, and look through code samples. You'll become a much better developer because of it.

Laughing at ourselves

2007-10-03T13:58:00.000-04:00

It's not as funny as many of their other "commercials", but they guys at Rails Envy have taken on ColdFusion

Good thing we ColdFusion developers have thick skins. They did forgot to mention, .NET, PHP, and Ruby when discussing languages. Who's your dad anyway?

Late breaking addition: It appears that Charlie Griefer has leaked some ColdFusion 9 concept art.

ColdFusion makes Worse than Failure

2007-09-19T16:19:00.000-04:00

Today's Worse Than Failure entry looks at some ColdFusion code. I'm not sure whether this is a good thing or a bad thing. On the positive side, the WTF was more about the code itself than the language. On the negative side, it was some pretty inept code.

Documenting ColdFusion custom tags in Dreamweaver (4/4)

2007-09-04T15:58:00.000-04:00

Part 4: Creating the Dreamweaver Extension

In part 2 we created our tag editor; in Part 3 we created our documentation. In this part we package these files up as a Dreamweaver extension. To create the extension we start with a .mxi file. Editing .mxi files can be tricky in Dreamweaver. I usually create the file as .xml, then rename it when I'm ready to create my extension. We begin by defining the name, version, Dreamweaver version required, author and description of our extension.

<macromedia-extension name="Our Template Extension" version="1.0"
type="Suite" requires-restart="True">
<products>
 <product name="Dreamweaver" version="6" primary="true" />
</products>

<author name="Luis Matthews" />

<description>
 <![CDATA[A custom tag definition for CF_ourtemplate]]>
</description>

Next we tell Dreamweaver where to place the files we created. Some of our files go into the Taglibraries directory, others go into the Reference directory.

<files>
 <file source="cf_ourtemplate.htm"
   destination="$dreamweaver/configuration/Taglibraries/ourTags" />
 <file source="cf_ourtemplate.vtm"
   destination="$dreamweaver/configuration/Taglibraries/ourTags" />
 <file source="TagChooser.xml"
   destination="$dreamweaver/configuration/Taglibraries/ourTags" />
 <file source="Reference.xml"
   destination="$dreamweaver/Configuration/Content/Reference/our/" />
 <file source="default.htm"
   destination="$dreamweaver/Configuration/Content/Reference/our/" />
 <file source="ourtemplate.htm"
   destination="$dreamweaver/Configuration/Content/Reference/our/" />
</files>

Finally, we tell Dreamweaver what type of files our tag is used for, and what .vtm files to use.

<configuration-changes>
 <taglibrary-changes>
   <taglibrary-insert>
     <taglibrary doctypes="ColdFusion,CFC,DWTemplate_CF" id="ourTags"
       name="Our Tags" servermodel="Cold Fusion"
       tagchooser="ourTags/TagChooser.xml">
       <tagref file="ourTags/cf_ourtemplate.vtm" name="cf_ourtemplate" />
     </taglibrary>
   </taglibrary-insert>
 </taglibrary-changes>
</configuration-changes>

</macromedia-extension>

Once our .mxi is created, we simply open the Macromedia Extension Manager, Choose File->Package Extension, Select our .mxi file and let the extension manager create the extension. Once this is complete, you can double-click your .mxp file to install your extension.

I hope that you found this series useful. There is a lot more that can be done with Dreamweaver Extensions and ColdFusion Custom Tags. Custom Tags have had a bit of a bum rap in recent years, but I believe that they still can be quite useful in the right situation.

Documenting ColdFusion custom tags in Dreamweaver (3/4)

2007-09-04T15:50:00.000-04:00

Part 3: Documentation

In part 2, I talked about creating the tag editor for our custom tag. In this part we document our tag within Dreamweaver's reference and tie that reference into the tag editor. We'll start by creating a Reference.xml file, since this is the first tag we're documenting. For future tags, we'll simple edit our existing Reference.xml. We could use one of Dreamweaver's existing ones, but we'll create our own reference book in our own directory in order to prevent problems when upgrading Dreamweaver. This will also keep our tags together. Our Reference.xml looks like this.

<?xml version="0.81" encoding="iso-8859-1" standalone="yes" ?>
<book name="Our Custom Tag Reference" language="our">
<topic_title name="Tag"/>
 <subtopic_title name="Description"/>
<default location="default.htm"/>

<topic name="cf_ourtemplate" location="ourtemplate.htm"
 id="Description">
 <subtopic name="Attributes" id="Attributes"/>
 <subtopic name="Example" id="Example"/>
</topic>

</book>

The main things that concern us here are the book name, book language, default location and our topics. We've set the book name to "Our Custom Tag Reference". The Language is set to "our" since this is our custom reference rather than say an HTML reference. The default location specifies an HTML file to be loaded by default when the book is opened. Our default.html simply has a description of what the reference exists for.

Our custom Tag Reference
Select the tag that you wish more information on. The second select box allows you to navigate the sections of the documentation.

The Topics and subtopics defin

e what sections will show up within each topic/subtopic dropdown in Dreamweaver's reference. You are not constrained to the same subtopics within each topic. In this case I've defined three subtopics for the topic of cf_ourtemplate

Description
Attributes
Example

Finally we get to the file on

this topic. ourtemplate.htm needs to contain a div with an id for each of the subtopics. The subtopics themselves and the content are up to you. I've included an example in the source. Once we have this installed in Dreamweaver we'll see a new entry in the References tab.

In the final part I'll explain how to package these files up and distribute them within Dreamweaver.

Documenting ColdFusion custom tags in Dreamweaver (2/4)

2007-09-04T15:31:00.000-04:00

Part 2: Basic tag editor

In part 1, I explained that we'll need to create two files for basic tag editing. In this part we'll begin by creating a file called cf_ourtemplate.vtm. The contents will look like this.


<TAG NAME="cf_ourtemplate" endtag="yes">
<TAGFORMAT NLBEFORETAG="1" NLAFTERTAG="1"/>
<TAGDIALOG FILE="cf_ourtemplate.htm"/>

<ATTRIBUTES>
  <ATTRIB NAME="title" TYPE="TEXT"/>
  <ATTRIB NAME="theme" TYPE="ENUMERATED">
    <ATTRIBOPTION VALUE="basic"/>
    <ATTRIBOPTION VALUE="full"/>
  </ATTRIB>
</ATTRIBUTES>
</TAG>

Our opening <TAG> defines the name of our tag, and whether or not the tag requires and end tag. <TAGFORMAT> can be left alone. <TAGDIALOG> defines where our tag editor .htm file resides. We next move down to the <ATTRIBUTES SECTION>. For our purposes there are two types of <ATTRIB> that we're concerned with. The first type is "TEXT" which will simply define an attribute with a space to fill in the value. The second type is "ENUMERATED", which will give you a dropdown list of choices. You define those choices using <ATTRIBOPTION>. At this point our .vtm file is complete.

Our tag editor is probably the most complex part of this process. Fortunately there are a lot of examples already built into Dreamweaver. Simple find a tag that has an editor that functions like what you are trying to do, and use that tag editor file as a template. Fortunately our tag editor for this example is fairly simple. The source code will be very helpful here. I'm not going to replicate the entire file since it's quite long. This is basically a standard HTML file with some custom javascript.

<script src="../../Shared/Common/Scripts/dwscripts.js"></script>
<script src="../../Shared/Common/Scripts/ListControlClass.js"></script>
<script src="../../Shared/Common/Scripts/tagDialogsCmn.js"></script>
<script>
var THEMELIST;
var theUIObjects;
var applyType = "dynamic";

function inspectTag(tagNodeObj)
function applyTag(tagNodeObj)

function initializeUI()
{
var theThemeScaleCap = new Array("basic","full");
var theThemeScaleVal = new Array("basic","full");
THEMELIST = new ListControl("thethemescale");
theUIObjects  = new Array(THEMELIST);
tagDialog.populateDropDownList(THEMELIST, theThemeScaleCap,
  theThemeScaleVal, 1);
}
</script>

We start by including some .js files and defining some variables. Next comes the inspectTag and applyTag functions which I've truncated since they are identical each time. Finally we have the initializeUI function where we define the values for our theme list and populate the drop-down box. next we'll include the required stylesheet.

<link href="../../fields.css" rel="stylesheet" type="text/css">

finally we'll add our text field and our dropdown.


<input name="thetitle" type="text" class="basicTextField"
id="attr:cf_ourtemplate:title" attname="title" required="true" />
<select name="thethemescale" class="oneWordOptionList"
id="attr:ccf_ourtemplate:themescale" attname="theme" editable="false">
</select>

That's basically it. For further reference on this topic, see Extending Dreamweaver -> Extension APIs -> Tag Libraries and Editors under Dreamweaver's help menu. In Part 3, l'll explain how to create custom documentation for our tag within Dreamweaver.

Documenting ColdFusion custom tags in Dreamweaver (1/4)

2007-09-04T15:24:00.000-04:00

Part 1: Introduction

I've been meaning to post on this topic for a bit, and after reading Ray Camden's post on custom tags, I thought now would be a good time. I realize that a lot of developers use CFEclipse these days, but for those who use Dreamweaver or have others sharing a server that use Dreamweaver, documenting custom tags within Dreamweaver can be quite helpful. In our case, we have application developers and editors/designers that share templates and other UI elements. We've also used this technique to encapsulate complex capabilities into simple tags for our editors/designers.

During these articles we're going to look at a fictional tag called <cf_ourtemplate> that contains attributes of "title" and "theme". Our tag has two themes called "basic" and "full". How the tag functions and what those themes are is irrelevant to this exercise, so I'll leave that to your imagination. When we're done we should have something that looks like the following.

In order to bring this to life, we're going to need to create

a cf_ourtemplate.vtm, cf_ourtemplate.htm, and TagChooser.xmlile to define the inline hints and the tag editor
a Reference.xml, default.htm, and a ourtemplate.htm file for documentation
a .mxi file to make installing into Dreamweaver easier

It is not my intention for this series to be an exhaustive reference. To that end, in instances where a more detailed reference is available, or where the reference code is self-explanatory, I'll keep my explanations to a minimum. In the second part, I'll discuss creating the vtm and htm files for basic tag editing. Before moving on, you may wish to download the source code.

A legitimate complaint about ColdFusion 8

2007-08-28T14:16:00.000-04:00

I spotted this post on MXNA last night that at first appeared to be yet another CF is Dead type post. I'm not sure why I read it, but once I reached the second paragraph, I realized that it contained a legitimate complaint about ColdFusion 8's AJAX implementation. I suspect a good number of folks ignored it due to the title, so I thought I'd give you all a second chance. I don't necessarily agree with all of the complaints, but I do hope that Adobe does address some of this in future versions. Note: I've disabled comments on this post since it's really just a pointer.

Putting Object Oriented CF in Perspective

2007-08-20T12:39:00.000-04:00

After reading this post from Ben Nadel last week, I got to thinking about an OO reality check. I'm doing an intro to OO in ColdFusion tomorrow for our staff, and one of the things I plan to emphasize is that these techniques are another tool for their toolbox. While there are times that OO will be the best tool for their project, there may be times where it makes little sense. I'm not going to pull out a nail gun, when a hammer is all I need. On the other hand, when I do really need the nail gun, sticking with a hammer is kinda silly. (not to mention slow)

The thing about OO is that it takes time to learn (I'm two years into the process, and still have a long way to go.) That doesn't, however, mean that I haven't been taking advantage of OO during that time. I see this as a Yahoo's problems are not your problems type situation.

But also realize that Yahoo's problems aren't necessarily your problems. There is no such thing as one-size-fits-all guidance. Strive to understand the advice first, then implement the advice that makes sense for your specific situation.

I code things the best way that I currently know, until I get into a situation where I say, "There's got to be a better way!", then I go out and figure out what that better way is. This not only grows my skills when I need it, but also means my applications use these techniques when they are required. I've read about this idea of development several times when dealing with design patterns. The idea is that design patterns were meant to be used to solve problems when they are needed. Using the most design patterns doesn't mean you win. I believe the same holds true for OO concepts. I've been recently dealing with an application written by a couple of developers who are no longer working with us. They were so focused on OO purity that they ignored many of CF's native features. In the right situation each of these decisions might make sense, but in this case, they combined for an application that is harder to maintain than it would've been if they had been focused on writing simple and maintainable code.

Perhaps Ben's difficulty in understanding a specific OO concept is that he's not yet really needed it. I'm not in any way suggesting that we don't spend time on learning things that we don't yet need to know. I've bookmarked some of the links from the comments to that post, and will read them as time permits; however, most of the code that I'm writing these days will continue to use Transfer, Reactor, or simple gateways and DAOs, which has been meeting my needs quite nicely. When I need something more, it's nice to know it's there, though. And please, keep up with the great posts and discussions on advanced topics.

The bottom line here is that effective development means using the right tool at the right time. There have been a number of times where I've started sections of code with comments explaining that if this section is expanded, it should be refactored to be more OO first (usually with a detailed explanation of what to do), but for the sake of simplicity and expediency, I’ve written it in a more procedural fashion. Occasionally, I go back and refactor those bits of code as the situation warrants. Other times, I just let them run as they are. It may not be the most textbook code, but I find it effective.

We need a new UI paradigm

2007-08-15T11:28:00.000-04:00

In my mind, one of the most exiting web 2.0 innovations for businesses (sometimes called Business 2.0) is mashups. The Summer edition of Innovations listed mashups and making data more available as trends in the business world. Working for a medical college, I can foresee the day when faculty members could use current medical trends to determine what areas to emphasize, or even analyze areas where the student body is weak in order to focus on those areas more. (Perhaps even both) The point is that in order to take full advantage of the increases in data accessibility, users will need to be able to create their own mashups. Of course I'm not advocating a Coghead type approach (I agree with Alex from Worse than Failure on this subject). I expect that developers will probably continue to build reusable mashups and reports, but for basic ad-hoc mashups to be effective, users will need to be able to do it themselves. The key to this, I think, will be the creation of a new UI paradigm.
If you think about it, most applications have general UI paradigms. If you are familiar with one Word Processor, you can perform basic operations on pretty much any word processor on the market. For advanced features, you've still got to learn the specific product. The same is true for everything from Email to mapping software (Google maps, or even something like Zillow don't work much differently than old standards like Mapquest.) The only questions left is "Who will introduce the new paradigm?", and "How long will it take to become Standardized?".

Gettin' Reorganized

2007-08-14T14:36:00.000-04:00

I came back from Vacation a few weeks ago to find out that my department is reorganizing. It's taken a few weeks to find out what exactly that means, but essentially I (and my colleagues) are in the process of deciding to either be full time web developers or move into middleware. It's an interesting decision to make. In my case, most of what I currently work on, falls under the middleware umbrella, but moving over there means probably less coding (at the very least less, ColdFusion coding, probably no Actionscript work, and most certainly no Flex). It would mean, however moving into other interesting things like identity management, and data integration, that would give the reconstituted web development group broader access to interrelated data from various systems. At the moment I'm trying to figure out whether it'll be more interesting enabling this access, or building the mashups that will hopefully be and end result. Decisions, decisions... In any event, I'll either keep this blog Adobe/Web related, or have it removed from MXNA.

Some thoughts on ColdFusion Evangelism

2007-07-18T11:42:00.000-04:00

In one of the comments to my Friday post, Barry B asked for my thoughts on ColdFusion's Strengths, and how they could be leveraged to get more companies on board with CF development. In my mind that called for more than a simple comment response. Below is the last of a series of posts exploring the topic.

In my last post, I talked a little bit about why I am a ColdFusion Developer. In my final post for this series, I thought I'd throw out some ideas on how Adobe can better evangelize ColdFusion. Bear in mind that these are just thoughts, and as such may or may not truly be viable ideas. I hold no claim to ownership on these ideas, so Adobe, or whomever can feel free to use them as they see fit. Mainly this is meant as a jump off point for discussion, rather than fully realized ideas.

The first thing Adobe can do is to better advertise. I receive regular mailings from Microsoft advertising .NET, as well as seeing their ads regularly in publications like eWeek, Baseline, etc... More importantly, my boss (who ultimately decides what we buy) sees those same ads. Sure, I receive emails from Adobe when new products come out, but my boss does not. Beyond that, the fact of the matter is that when I do receive one of those emails, I tend to file it away to look at later, and move on to the more time sensitive emails. Two guesses as to how often I get back to the Adobe mailings. As a direct result, while we would be good candidates for using Flex, I don't see that happening anytime in the near future. I've mentioned it a few times, but it's been difficult to put together a compelling business case for a product that my boss has barely heard of. (Reminds me of the old catalog service "Everything you've never heard of but can't live without".)

The second thing Adobe can do is put Livedocs out of it's misery, and replace it with something better. One would think that between Flex and ColdFusion, Livedocs would be a showcase of how to build a compelling rich internet application. Livedocs was great back in the day, but it's getting more than a little long in the tooth at this point.

My third suggestion would be to recreate the CF Pet Market application in competing languages (PHP, .NET, Ruby, etc..) using best practices in those various languages, then posting a series of articles highlighting specific areas where CF shines.

My final, and probably most controversial suggestion is for Adobe to release a free version of CF server that can be used in a production environment. I'm thinking something that sits say below Standard edition, with support for maybe 95% of the tags (i.e. no reporting, no pdf work, no image work, etc..), and reducing the number of built-in database drivers (perhaps keeping only mysql and access). The idea here would be to put CF on an equal footing price-wise with the PHPs of the world at least for getting in the door. Once users have an investment of time in CF, I suspect the cost of upgrading for the more robust pay version would be less of a concern than it is today. It might also mean more developers learning CF in the first place.

Well, there you have it, during this series of posts, I've discussed Why CF is not dead, why I use CF, and finally with this post, added some thoughts on how Adobe can better evangelize CF. Hopefully you found some of these ideas interesting.

Why I'm a ColdFusion Developer

2007-07-16T15:32:00.000-04:00

I ended my last post by stating that I didn't think it really mattered whether or not ColdFusion is dying. It certainly matters to Adobe, but for a lot of us, this question only starts to truly matter if they should discontinue working on it. (and even still, I would expect companies like New Atlanta to probably pick up the ball). The important question in my mind is not, whether or not CF is dying, but whether or not it is still the best tool for the job that we're asking it to do. Do we stick with it or can we justify the cost of moving onto something else? To be perfectly honest this is a question I ask every couple of years. As of last time we seriously looked at the subject (When MX 7 was released) the answer was "yes".

The title of this post is why I am a CF developer. For me it started with working on some web-based tools for a newly installed LDAP server. I had been working in Perl using the Perldap module. Our other developer was working on some initial projects for a newly installed CF 4.5 server, and I decided to take a look at it. I'm not quite sure how they decided to get started with CF in the first place. In any event, I saw that what was taking me 50 lines of code could be done in 1 with cfldap, I immediately switched over. About 6 Months later a web group was formed in the University, and my job moved over. (even though I was only doing web part time then) Our new web group found itself supporting both CF and ASP applications. .NET saw the migration of our ASP apps to CF, and we've been a CF shop ever since.

Probably the number one reason we did not move to .NET is that we are a mixed group of designers and developers. Being tag based, ColdFusion allows our designers and developers to easily collaborate on projects, while working in the same environment. It's just not realistic to expect our designers to learn VB or PHP, when they can learn a few new tags as needed. There were of course other reasons we chose (and still choose) to stick with ColdFusion. Most of these Peter Bell listed in his "ColdfFusion - Why Bother?" post last month, so I don't feel the need to repeat them.

In my next post I'll conclude this series with some thoughts on what Adobe can do to better evangelize ColdFusion.

Why ColdFusion is not a dead language

2007-07-16T11:32:00.000-04:00

Let's start by talking about why ColdFusion is not a dead language. Wikipedia defines a dead language as, "a language which has stopped changing in grammar, vocabulary, and the complete meaning of a sentence." Furthermore it distinguishes between the concepts of a dead language and an extinct language. The latter being, "a language which no longer has any native speakers" While we all know that Wikipedia is not the end-all be-all font of all knowledge, in this case it's accurate enough for my purposes. By these definitions, ColfFusion is not a dead language; it's being actively developed. While technically I suppose all programming languages fit the definition of extinct since nobody natively speaks them. If we expand native speakers to include those who use a programming language as their primary development language, then ColdFusion is not extinct either, as there is clearly an active body of vocal developers. (Not to mention the developers who just focus on getting their jobs done and can't be bothered reading stuff online about languages.)

Ok, so if CF is not dead yet, is it dying? Before we get into that we need to look at marketshare, and total number of users. These are two concepts that I think all too often get mixed up. In spoken languages, Mandarin Chinese (at c. 873 million native speakers), is pulling away from English (at c. 309 million native speakers). English is not likely to catch up in any of our lifetimes, and will likely continue to loose marketshare, but the total number of English speakers is rising as the populations of the US, UK, Canada, and Australia grow. In my mind marketshare is less important to the health of a language than total number of users. With CF, I'll concede that marketshare has probably been decreasing, as there are simply more and more languages out there to use. I honestly have not seen any figures that prove or disprove this, but for the sake of argument I'll concede that point. As far as total number of users, I have no idea if that number is going up or down. (I'm not sure if Adobe publishes those types of numbers) The bottom line here is that I really don't know if CF is dying or not. I'm not sure how much that matters though. More about that in my next post.

The Rumors of ColdFusion's Death are greatly exaggerated

2007-07-13T16:04:00.001-04:00

In my web wanderings I came across another article claiming that CF is dead. Couldn't find any way to provide feedback.

Log Parser saves the day (again)!

2007-06-05T14:57:00.000-04:00

If you're like me and work for a somewhat smaller organization (IT wise at least), you too probably wear multiple hats. In addition to development tasks I often find myself asked to provide stats and data from our web logs that don't exactly show up in standard log analysis tools.

Today the request was to determine what IP addresses accessed a particular directory during a particular period in time. This is something our log analysis tool definitely does not do. Enter Microsoft's Log Parser. Log Parser is a command line tool from Microsoft that allows you to use SQL to filter a large variety of text file formats (including IIS and ColdFusion logs), and output the results in a number of formats. Two quick SQL statements later and I have a CSV file with the IP addresses in question. If you are a Windows user who finds themselves performing these types of tasks, you should seriously consider adding Log Parser to your toolkit.

For information on using Log Parser, check out Charlie Arehart's excellent article from the October 2006 CFDJ. To download it, go to Microsoft's web site and do a search on Log Parser. (I find that anytime I put up a link directly to a Microsoft resource, they end up moving it on me.)

Best use for CF custom tags?

2007-05-23T14:13:00.000-04:00

It's been quite a while, so I thought I'd post a question about how and if folks use custom tags in ColdFusion. I work in a mixed environment of designers and developers. The developers in our group (myself included) have found that a good way to deliver reusable snippets of functionality to our designers is to encapsulate them in custom tags, then add them to Dreamweaver's tag libraries via an extension. If there's any interest, I'll write up a post on how this is done.

I feel like I should state at this point that we are very careful about what tags become global tags and what tags need to be imported before use via . We currently have fewer than 6 global custom tags, however those that we have are heavily used. As an example we've written a "replacment" for , that functions exactly like with the exception that it effectively defaults a lot of the values in that are specific to our LDAP. Another example is a login tag that can be placed into an Application.cfm that will authenticate the user againts our LDAP. This tag utilizes the same cfc as the previous tag for it's ldap functionality.

So do you use custom tags? How?

Did Adobe drop the ball on DST changes?

2007-02-27T15:36:00.000-05:00

This post is about the upcoming Daylight Savings changes in the U.S.

OK, so let's start with some facts:
ColdFusion 7.0 uses Java Version 1.4.2_05
ColdFusion 7.0.2 (which came out November 30, 2006) uses Java Version 1.4.2_09
According to an Adobe Technote you need Java Version 1.4.2_11 in order to be compliant with the new DST dates for 2007.
The Technote does not currently appear on the main ColdFusion Support page. You have to search for it.
The instructions linked from said Technote are fairly detailed on how to upgrade the Standalone version of CF, but despite the title, don't apply directly to multiserver installs.

This all leads me to the following questions:
If Adobe has updated Java versions in the past, why have they not made a patch for this?
Why does this information not appear on the main ColdFusion Support page?
Why are the instructions not more detailed and specific to the different install options?
Am I asking for too much?
Did I miss something?
Did Adobe drop the ball here?
Will the world blow up on March 11?
Will I actually update this post when Adobe's knowledgebase becomes available again?

I welcome any input from anybody who can answer any of these questions.

I was wrong, and other housekeeping

2007-02-02T12:02:00.000-05:00

I'll start with the housekeeping. I haven't posted in quite a while, mostly because I haven't had anything to say. I don't kid myself that I have any regular readers, and in this day of aggregators, I find myself very comfortable with posting only when I have something to say.

Shortly after my last post, it was pointed out to me that I was missing the point of that particular discussion. I didn't agree at the time, but since then I've come to concede that perhaps that was the case. I briefly considered retracting the post, but I decided to leave it for posterity.

I never did make that post about my Model-Glue issue. Upon further review, it was 100% PEBKAC related, and not something that would be easy to duplicate.

Can't we all just get along?

2006-09-29T09:39:00.000-04:00

Well it seems that there is another flurry of posts about frameworks again. (See Sean Corfield's recent post, which has links to several relevant posts. Not for the faint of heart.) All I have to say, is why can't we all just agree to disagree and move on? If you don't like frameworks, then simply don't use them! If you're worried about folks who are new to ColdFusion or OO trying to use framworks, why not take the time to help them along, rather than worry about what they're not ready for yet? Saying frameworks suck because some people are not experienced enough to use them yet, is like saying grocery stores suck because some people can't cook.

Bloggers, here's what I propose. Next time you feel the urge to post a pro-framework or anti-framework post, do the following instead.

If you are anti-framework:
Write a post explaining an intermediate or advanced CF or OO concept in plain English¹ with a simple example.

If you are pro-framework:
Write a how-to post takling one topic of your favorite framework in plain English¹ with a simple example. It would probably be best to pick something that is not covered in the existing documentation, or that may be unclear or vague to you.

As for me, I plan to work up a post asap, explainig a problem² I recently encountered while using Model Glue, and how I resolved the problem.

¹Feel free to repace English with whatever your native language is.
²Developer problem, not a Model Glue problem.

We're back and we have the combination...

2006-09-21T14:08:00.000-04:00

Wow, August and September have been crazy for me between being short two people at work, some much needed vacation time, and some major changes in my personal life, I've barely had time to sleep let alone post. Not much new around here other than the design, which is in the process of changing yet again. The current version is based on an article over at A List Apart called In Search of the Holy Grail.

Should ColdFusion developers be more Java-like?

2006-07-28T12:31:00.000-04:00

As the ColdFusion community is thinking about what we'd like in CF 8, it dawns on me that in some ways we're going through growing pains. In discussing and disagreeing with desired new features, we're asking, "What do I want to be when I grow up?" Should the ColdFusion community as a whole stay focused on web pages with interactivity, or should we start thinking and acting like application developers?

Personally, I answered that last question for myself last Summer after we hired a Java developer. Through discussions with him, I realized that I was building web based applications, but treating them as if they were web pages with interactivity. Because of this, most, if not all of my projects ended up being nightmares to maintain, often with quick-fix solutions tacked on later. At that time I decided that I needed to start thinking like, and ultimately become an application developer (since that was what I was in fact doing for a living.)

Where I work, we pretty much use ColdFusion for our websites. In the past we've used ASP, and Perl, but for the most part we're a CF shop. The reason for this and the main reason we stick with it is that using CF allows our web designers to work alongside of our developers using the same IDE (Dreamweaver), while all still being productive and focused on our individual strengths. Sure, our HTML folks have picked up a bit of CF here and there, much the same way that as a CF developer I know some HTML, but for the most part they are experts on graphics and HTML, whereas I'm expected to be the expert on CF. What this has meant is that when our designers need some complex capability, our developer's encapsulate it in a ColdFusion Tag and document it with a dreamweaver extension. The designers simply need to learn one new tag, and they're off to the races. (heck, Dreamweaver even lists out all the attributes for them.)

My point is that while, I don't want to see the ease of entry into ColdFusion change, I do think that those of us who write ColdFusion based web applications for a living need to keep up with and take advantage of the programming innovations and techniques that are in use in other languages such as Java. There are some that do so, but far too few of us. I've learned a great deal from our Java brethren in the past year, and I'm sure there are plenty of lessons to learn from those working in other languages as well. We need to seek out those opportunities and share them within the ColdFusion community.

Will this create a divide in our community? I really don't think so, rather I think that by learning from our Java brothers, we may find opportunities to share with them as well, and in the process perhaps broaden the appeal of CF. All I can say definitively, is that for my part, I've managed to show one Java developer the strengths of CF in such a way that he now prefers CFML to JSP for his web based applications.

Wishlists and Drugs

2006-07-27T10:01:00.000-04:00

There has been an almost dizzying amount of blog posts lately about what folks desire to see in ColdFusion 8. Personally I think I've been reading too many of them for my own good, because sometime yesterday afternoon I got the following image stuck in my head.

Obviously between work, wishlist blog posts, and the new comic series over at Fusion Authority, I've gone and fried my brain. Don't get me wrong, I write OO CF code, and there is a reasonable chance that I would utilize interfaces if they were available in CF, but part of me hopes that CF 8 is more evolutionary than revolutionary. Realistically, most of my co-workers are still writing CF 5 style code, and despite my efforts I don't see that changing overly quickly.

Getting Animated

2006-07-18T14:34:00.000-04:00

In an attempt to provide some relief for my brain which is quickly frying due to: (in no particular order)

The extreme heat in the North East
Being short-staffed at work due to openings, illness, new babies, and vacations
Trying to learn too many new technologies at once

I've decided to animate my logo. While this may sounds like a simple task, I've decided to do an animated version of the wandering fishbowl using Action Script 2.0. The first question that probably popped into your mind is, "Why? Wouldn't just doing an animated .gif be easier?" The answer is, "Yes, it would be easier". But that's not really the point. The point of this blog is to give me a place to try things out that I've not done before. I started learning Action Script when ColdFusion MX 7 came out because I could forsee a time when Action Script skills would be as important for a CF developer as HTML skills are now. With the recent release of Flex 2, I'm more certain than ever that this will be the case.

Creating an AS version of the logo gives me an opportunity to continue to work on those skills without having to delve in to Flex 2 (yet). Beyond that, I'm thinking that ultimately I'm going to end up with smoother and more randomly animated image than I could using more traditional methods. Time will tell, and I'll post samples as they become available.

Look and feel update

2006-07-11T13:23:00.000-04:00

The first phase of the look and feel update has occured. There's a distinct lack of navigation at the moment, but hopefully by the time there are enough posts to justify navigation I'll have the problem fixed.

On the ColdFusion front

2006-07-06T15:13:00.000-04:00

On the ColdFusion front I've been working on a project using Model-Glue:Unity. I must say that between Reactor and scaffolding, it's super quick and easy to get something up and running. I've been able to quickly show my client the prototype and incoporate feedback with minimal effort.

I've been reading a bit about Duck-typing as well, but I've not fully digested it yet, so I'll probably wait a bit before I put in my $.02. (although I did comment on one of Sean Corfield's blog entries.)

Look and feel

2006-07-06T15:10:00.000-04:00

Considering that one of the main reasons behind starting this blog was to explore some of the more presentation-end technologies that I'm not as up to speeed on as I'd like, such as XHTML and CSS, we should hopefully be seeing a new look for this site. Well, eventually.

Taking a Java course

2006-07-06T14:24:00.000-04:00

I've been wanting to learn some Java for a while, so when I learned about the free course being offered at http://www.javapassion.com, I signed up immediately. Truth be told, this is the main reason this blog has been so slow in getting off the ground. For the most part I'm finding it clear and fairly easy to follow, although I must say, I'm having my issues with the "this" scope. It doesn't seem to work the way that it does in either CoildFusion or Actionscript.

Starting over

2006-07-06T14:16:00.000-04:00

I had originally started this blog back in April, however, life as always got in the way. (The details of which are neither interesting nor relevant.) To make things simple, I decided to start over with this blog. Most likely you'll see a bunch of posts over the next week or so, followed by sporadic posting between now and September.