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.