Builder Extension using HTML

One of the cooler features of ColdFusion Builder’s extension tooling is the ability to create extensions that are driven with HTML/JS/CSS instead of with the default XML options. I think this has a few advantages:

  • Allows interface options enabled by the XML options
  • Allows better branded extensions via CSS and background images
  • Allows you to develop/debug your extensions like normal web applications

This is pretty easy to enable. Normally you would have code like this in your handler to communicate back to the IDE:

<cfheader name="Content-Type" value="text/xml">
<response status="success" showresponse="true">
    <ide >
        <dialog width="600" height="400" />
        <body>
            <![CDATA[
                Some Response
            ]]>
        </body>
    </ide>
</response>

Instead you pass a URL parameter to the ide tag in your extension handler:

<cfheader name="Content-Type" value="text/xml">
<cfoutput>
<response showresponse="true">
    <ide url="http://localhost/extension/handler.cfm?configPath=#configPath#" >
        <dialog width="655" height="600" />
    </ide>
</response>
</cfoutput>

As you can see it can even handle URL variables.

Now, where I ran into trouble with this was with the URL itself. Basically you can’t be sure of the URL when dealing with extensions. It could be localhost, but it just as easily could be on a remote server. So I was all clever and wrote some code to handle this:

<cfset baseURL = "http://" & cgi.server_name  />
<cfset messagesPath = getDirectoryFromPath(cgi.script_name) & "/messages.cfm" />
<cfset messagesOptions = "?type=notanapplication" />
<cfset messagesURL = baseURL  & messagesPath & messagesOptions >

 

You see, this will give me the correct URL to use to pass information to a template named “messages.cfm” that sits in the same folder as my handler. I use CGI variables to grab the server information. Then I use getDirectoryFromPath to make sure that I get the real relative path of the folder that the extension is sitting in (as opposed to assuming that it lives in the webroot). This works great.

Except I got reports of one of my extensions not working at all for some people. Look at that code again… There’s another big assumption there. The assumption is that the extension is being called over the default http port, which for many ColdFusion developers it isn’t. So the correct version of this code goes:

<cfset baseURL = "http://" & cgi.server_name & ":" & cgi.server_port />
<cfset messagesPath = getDirectoryFromPath(cgi.script_name) & "/messages.cfm" />
<cfset messagesOptions = "?type=notanapplication" />
<cfset messagesURL = baseURL  & messagesPath & messagesOptions >

Doing this you can be sure that you hit the right URL regardless of:

  • Server hostname
  • Server http port
  • Relative location of extension to the webroot

Happy extension building.

Apptacular Update and Video

I know I’ve been quiet of late. But I’ve been working.

You see a few weeks ago I had this checklist up on the site:

  • Make sure apptacular_blog database works on MySQL on MAC.
  • Make sure apptacular_blog database works on MySQL on PC.
  • Make sure sakila database works on MySQL on MAC.
  • Make sure sakila database works on MySQL on PC.
  • Make sure apptacular_blog database works on MSSQL on MAC.
  • Make sure apptacular_blog database works on MSSQL on PC.
  • Make sure adventureworks database works on MSSQL on MAC.
  • Make sure adventureworks database works on MSSQL on PC.
  • Fix major issues in code readability.
  • Start Document how to work with Apptacular

See those AdventureWorks database items? They nearly killed me and made me want to stop work on Apptacular. AdventureWorks is like a cruel Double Dare obstacle course for code generation:

  • Composite primary keys
  • Composite foreign keys
  • Composite primary keys that are also foreign keys
  • Custom Datatypes
  • Constraints (Really only affected unit testing).

I came through, and now I can give you this list:

  • Make sure apptacular_blog database works on MySQL on MAC.
  • Make sure apptacular_blog database works on MySQL on PC.
  • Make sure sakila database works on MySQL on MAC.
  • Make sure sakila database works on MySQL on PC.
  • Make sure apptacular_blog database works on MSSQL on MAC.
  • Make sure apptacular_blog database works on MSSQL on PC.
  • Make sure adventureworks database works on MSSQL on MAC.
  • Make sure adventureworks database works on MSSQL on PC.
  • Fix major issues in code readability.
  • Start Document how to work with Apptacular

So that’s where I am. A few of you asked if you could get your hands on Apptacular and I would be happy to distribute it to individuals. I’m not ready for general availability yet though.

And as a final note, I thought I would share this feature with you: Apptacular can model CRUD for image fields in your database.

http://vimeo.com/moogaloop.swf?clip_id=9159214&server=vimeo.com&show_title=1&show_byline=1&show_portrait=0&color=00ADEF&fullscreen=1

Apptacular ColdFusion Builder Extension – Working with Images from Terry Ryan on Vimeo.

Flash and Apple

This is more a stream of consciousness piece than a well-developed thesis. I’ve had these thoughts thundering around upstairs and needed to get rid of them.

I really like Apple and their products. The MacBook Pro saved me from Vista, and I haven’t looked back. The iPhone is a great piece of technology. I would really want an iPad if I didn’t have a Kindle already. I have to say I’m really disappointed by all of this Flash and Apple nonsense. I’m also happy to read that some other people are disappointed by this (Gizmodo, Digital Beat, MacRumors Forum, FucktheIpad).

Some of Apple’s justification for the lack of Flash, namely performance issues, seems to fall a little flat here. Supposedly by designing the chip themselves, Apple has a chip that can render webpages instantly and still play video for 10 hours. It would appear that performance isn’t really the issue with the iPad.

That being said I have never really understood the whole Flash-performs-poorly-on-Mac thing. I work for Adobe. I am a member of the Flash Platform evangelism team. I use multiple Flash applications, every day of my life, for hours on end. I don’t have browser crashing issues. I currently use Chrome, and used Firefox before that. I never really gelled with Safari. I’m not being obtuse here, or acting, I just don’t have those particular problems. I’m not running a special version of Flash Player either; I just use the latest released version.

I also don’t understand cognitive gymnastics it takes to hate Flash because it’s proprietary and love the fact that Apple is batting us around by designing systems that block it by way of preventing one from installing it through a proprietary gatekeeper.

Flash is proprietary. It’s also free, widely distributed, rapidly brought up to date on user’s computers, and cross platform. Yes, to some degree you have to depend on Adobe. This is true. Even worse, we get something out of it–we sell authoring tools, content creation tools, services, and servers that target that dependency.

With HTML 5 you don’t have to depend on anyone….

Except browser authors: Opera, Mozilla, Google, Microsoft, and Apple. But they all conform to the HTML 5 standard…

Okay, they don’t yet but they all have detailed plans that outline when they will support HTML 5…

No they don’t. But they don’t get anything out of it…

Except access to your data, or locking you into their operating system, or locking you into their operating system and hardware or whatever ideologically pure motivation Mozilla and Opera have these days.

At the end of the day, all of these technologies are driven by mutual self-interest and not by ideology. You have to decide if what you get is worth what you give up.

Personally I don’t like being told what to do. But more important than not liking being told what to do, I enjoy being told how to do it even less. I don’t like opinionated software that promises Do it the way we tell you to, and we’ll make your life better.

  • I didn’t like Graffiti.
  • I don’t enjoy working with Ruby on Rails.
  • I don’t like the Apple Mobile device’s increasing demand that I work the way they want me to.

At the end of the day, despite the fact that they may not be well expressed or even coherent, I have more faith in my opinions than my software’s opinions.

Builder Stats

You may have seen my previous posts about Apptacular. I’m getting pretty far along in it, and I wanted to figure out how many lines of code I had written, you know, for my only curiosity’s sake. There’s no easy way of doing this, but I figured that this was the perfect excuse to build another extension.

So basically I wrote an extension that will count every nonblank line in every file in a targeted folder. It then groups those line counts by folder, extension, and then just all files.

This extension isn’t going to change anyone’s life. But it’s a great example of the fact that ColdFusion Builder extensions remove barriers to entry for this sort of thing. If I had to drop to Java to extend this in Eclipse I would have never done it – too much work for too little reward. But with ColdFusion Builder extensions in ColdFusion there’s very little cost to indulging in this sort of experiment:

  • 10 minutes to write the base code
  • 10 minutes to turn it into an extension
  • 1 hour getting the formatting right to share publicly. (CSS is sadly harder then ColdFusion)

Feel free to use it, and improve on it: BuilderStats at RIAForge.

Apptacular Plans

A few people have asked: When will Apptacular be released?

Short answer: I don’t know.

Long answer: I have a plan. Read on.

Before I release Apptacular, I want to make sure that it’s solid. Right now it works with the database I have but I know it will fall down when it hits a “real” database. The fix for that problem is to run it against demo databases that come with various RDBMSs. I’m targeting sakila for MySQL and AdventureWorks for MSSQL.

Also the source is somewhat hard to follow. There is no documentation. Most people won’t give a project a second look unless the documentation can at least get them started. Most potential contributors won’t even try to jump in unless the source is manageable.

So to those ends I have sort of a checklist to go through before I release the extension and code:

  • Make sure apptacular_blog database works on MySQL on MAC.
  • Make sure apptacular_blog database works on MySQL on PC.
  • Make sure sakila database works on MySQL on MAC.
  • Make sure sakila database works on MySQL on PC.
  • Make sure apptacular_blog database works on MSSQL on MAC.
  • Make sure apptacular_blog database works on MSSQL on PC.
  • Make sure adventureworks database works on MSSQL on MAC.
  • Make sure adventureworks database works on MSSQL on PC.
  • Fix major issues in code readability.
  • Start Document how to work with Apptacular

So I’ll keep you all up to date on where it is. If you want to test it ahead of time, and are willing to deal with bugs, then drop me a line in the comments.

Apptacular ColdFusion Builder Extension – Unit Tests

I just cannot get enough of making videos for Apptacular it seems. This latest one is about unit tests, specifically MXUnit tests. I need to test if Apptacular is creating applications properly. I wrote up some traditional unit tests for my code, but I really need to test the code that Apptacular makes. So I got it to generate unit tests that help me determine if the applications that Apptacular creates actually work. However, in the process I have to wire up a few things that make it really easy for you to get started writing unit tests in your applications. So it’s a win-win.

The generator does some smart things like wiring up ORM tests that test across many-to-one relationships. (I haven’t figured out how to do one-to-many or many-to-many yet.) Anyway, check out the video.

http://vimeo.com/moogaloop.swf?clip_id=8264930&server=vimeo.com&show_title=1&show_byline=1&show_portrait=0&color=00ADEF&fullscreen=1

Apptacular ColdFusion Builder Extension – Unit Test from Terry Ryan on Vimeo.

ColdFusion Builder for Dreamweaver Shops

I was asked on Facebook today: “Hi, is this builder applicable if
you are a DreamWeaver shop? Looks interesting. I see it uses eclipse.
I’m trying to see the value in looking at it.”

This is a great question, and like most the answer is: it depends.

If you are a Dreamweaver shop because Dreamweaver has
traditionally included ColdFusion support, and is a more capable solution
then other actively developed ColdFusion editor choices to date, then
ColdFusion Builder is definitely for you. We definitely go beyond what
Dreamweaver can offer in terms of ColdFusion support. If Dreamweaver is
simply “good enough” for your ColdFusion development, but you don’t
leverage all of the HTML GUI goodness that Dreamweaver has to offer,
then ColdFusion Builder is definitely for you.

If you are doing complex DOM manipulation in your front-ends
and really need to be able to drill into those manipulations or if you
use Design view a great deal in your development process then
Dreamweaver may still be the product for you.

Here’s a little feature comparison chart to help you out.

ColdFusion Builder ID Comparisons

Update:  The origianal version of this chart failed to recognize that Homesite had FTP support.  Sorry about that. I thought I had fixed that.  Also Homesite had a way of being extended via VTML. Dreamweaver is extensible via JavaScript.  However neither are/were extensible via CFML.