Hating Online Only Help in Creative Suite

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.

Labels: Adobe, Dreamweaver, Flash

posted by Luis - 3 comments

CF Developer needed in Philadelphia, PA

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.

Labels: Actionscript, Adobe, ColdFusion, Contribute, Contribute Publishing Services, Dreamweaver, Flex, Object Oriented Programming

posted by Luis - 0 comments

Odd LDAP Calls from Contribute Publishing Services

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.

Labels: Adobe, Contribute, Contribute Publishing Services, LDAP

posted by Luis - 0 comments

Future ColdFusion Features

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.

<cfsite type="brewpub" skin="blue" name="Nodding Head" location="Philadelphia, PA" />

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.

Labels: Adobe, ColdFusion, Humor

posted by Luis - 0 comments

Testing is hard work!

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.

Labels: Actionscript, Adobe, AJAX, ColdFusion, Flash, Flex, user interface, web 2.0

posted by Luis - 0 comments

Should we extend CF Objects with java APIs?

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.

Labels: Adobe, ColdFusion, Java

posted by Luis - 0 comments

IDE Survey Relevance

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.

Labels: Adobe, ColdFusion

posted by Luis - 0 comments

FCKeditor can meet your rich text needs.

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.

Labels: .NET, Adobe, AJAX, ColdFusion, FCKeditor, PHP

posted by Luis - 0 comments

Think More, Code Less

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.

Labels: Actionscript, Adobe, ColdFusion, Flash, Planning Series

posted by Luis - 0 comments

Coding with the Stars

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.

Labels: Adobe, ColdFusion

posted by Luis - 0 comments

Laughing at ourselves

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.

Labels: Adobe, ColdFusion, Humor, Ruby

posted by Luis - 0 comments

ColdFusion makes Worse than Failure

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.

Labels: Adobe, ColdFusion, Ineptitude, WTF

posted by Luis - 2 comments

Documenting ColdFusion custom tags in Dreamweaver (4/4)

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.

Labels: Adobe, ColdFusion, Custom Tags, Dreamweaver

posted by Luis - 0 comments

Documenting ColdFusion custom tags in Dreamweaver (3/4)

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.

Labels: Adobe, ColdFusion, Custom Tags, Dreamweaver

posted by Luis - 0 comments

Documenting ColdFusion custom tags in Dreamweaver (2/4)

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.

Labels: Adobe, ColdFusion, Custom Tags, Dreamweaver

posted by Luis - 0 comments

Documenting ColdFusion custom tags in Dreamweaver (1/4)

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.

Labels: Adobe, ColdFusion, Custom Tags, Dreamweaver

posted by Luis - 0 comments

A legitimate complaint about ColdFusion 8

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.

Labels: Adobe, AJAX, ColdFusion

posted by Luis

Gettin' Reorganized

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.

Labels: Actionscript, Adobe, ColdFusion, Flash, Flex, mashup, middleware

posted by Luis - 0 comments

Some thoughts on ColdFusion Evangelism

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.

Labels: .NET, Adobe, CF Is Not Dead Yet Series, ColdFusion, Evangelism, Flex, Microsoft, PHP, Ruby

posted by Luis - 5 comments

Why I'm a ColdFusion Developer

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 second of a series of posts exploring the topic.

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.

Labels: .NET, Adobe, CF Is Not Dead Yet Series, ColdFusion, Microsoft, PHP

posted by Luis - 3 comments