TerrenceRyan.com

I'm a 35 year old redhead geek from Philly.
I'm currently a Developer Evangelist for Adobe.
Also the author of Driving Technical Change

Builder Extension using HTML

1 Comment

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:

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:

Happy extension building.

1 response so far ↓

  • 1 Raymond Camden

    The code you used to determine the URL should also sniff for http versus https. Of course, I seriously doubt someone is going to be running an extension off a secure server like that.

Leave a Comment









Categories

Monthly Archives

Tag Cloud

coldfusion web development flex coldfusion builder appearances squidhead coldfusion builder extensions higher ed flash builder air mobile android adobe apptacular html5 driving technical change running a coldfusion shop adobemax06 movable type flash catalyst flash blackberry adobemax07 adobemax08 hero finicky css adobemax09 holy crap i’m a mobile developer centaur basecamp cfc unfuddle motorola metablog irrational characters ios git evangelism devices code reviews ant wharton subversion security phonegap philly philadelphia multidevice knowledge@wharton jobs browserlab adobemax10 adobe tv unfuddlecfc svnauth.cfc semantic html semantic html responsive web design qnx nlb linux jquery mobile java it github flexorg fireworks edge eclipse dreamweaver apps apple adobemax11