Work on the Komodo-CFML front

Things on the Komodo-CFML front have been pretty quiet here of late, but that’s not because nothing has been going on. I threw everything out and started over, and I’m now close to having a completely rebuilt version ready to release.

Things on the Komodo-CFML front have been pretty quiet here of late, but that’s not because nothing has been going on. Several months ago, as I wrestled with some odd behavior I was seeing with the extension under then-new Komodo v9, I came to the conclusion that there were a couple of fundamental problems with the approach I had taken in tokenizing CFML (used in Komodo to provide syntax colorizing). Furthermore, that approach appeared to make it nearly impossible to do much in terms of any sort of code intelligence-type help.

So… I started over. Completely. Threw everything out and started from the ground up, building an entirely new version of the extension. (Actually, I started over three times, trying to make sure I had a better approach.) At one point, I got stuck waiting for resolution of a bug relating to how Komodo creates the skeletons of extensions.

At this point, I am very close to having this completely-rebuilt version ready to release (probably as a v0.2.5). I’ve tried to make sure it provides everything the current v0.2.4 does in terms of syntax highlighting, but it also has a couple additions:

  • completely reworked DTDs for CFML + HTML5 (for both CFML v10 and v11), with content models that provide better and more consistent access to CFML tag and attribute completion
  • CFML language keyword, scope, and function name completion (this is what I started working on and ended up heading down the rabbit-hole that led me to scrap everything and start over)
  • macros for CFML help for the word under the current caret position and for CFML comment/uncomment region that work in a manner consistent with Komodo’s built-in comment/uncomment region (more on this at some later date)

So… I’m close. Close enough that I have been using this new (still evolving) version for my daily development work for several weeks. I’m waiting for one additional Komodo bug to be resolved (hoping it will be included in Komodo v9.3, which is in the nightly-build prerelease stage at this point). I will post something here when I release it, as well as making it available through the Komodo packages repository.

Komodo-CFML v0.2.4 available

Version 0.2.4 of my language extension supporting CFML for ActiveState’s Komodo IDE/Edit is now available.

Version 0.2.4 of my language extension supporting CFML for ActiveState’s Komodo IDE/Edit is now available. This update represents a minor bump in the version number but also represents more work behind the scenes than any update in recent memory, as all of the plumbing in the extension has been replaced so that it will work with the forthcoming Komodo v9 releases while still working with Komodo v8.x in addition to the changes below.

A Quick Summary of Changes

In addition to the rework noted above to support Komodo v9, this update provides the following changes:

  • Tag and attribute support for Adobe ColdFusion v11
  • Numerous updates and fixes to the tag and attribute support for Adobe ColdFusion v10
  • Switched to cfdocs.org for CFML-specific language help
  • Includes a small set of CFML-specific macros (look for “CFML Tools” in Komodo’s Toolbox panel) and puts the scaffolding in place for language-specific macros, snippets, abbreviations, etc.
  • A minor change to the syntax highlighting applied to CFML comments occurring within function calls (very edge-case-ish)

A Note About Installation/Upgrading

With this update, you will notice that the structure of the name of the editor extension file itself has changed. Where in the past, the editor extension file was named cfml-0.2.3-ko.xpi, this version is named komodo-cfml-0.2.4a0-ko.xpi. There are two changes there to note:

  • The base part of the file name has changed, primarily as part of the reworking of the basic structure of the editor extension for compatibility with Komodo v9; and
  • I have changed the embedded versioning information for the extension so I have a bit more flexibility in how I keep track of updates and additions to the extension.

With these changes to the name of the editor extension file, you will want to explicitly uninstall whatever version of Komodo-CFML you may currently be using and then install this new version to avoid any sort of potential confusion within Komodo about how CFML files are to be handled.

Download

The updated version of the extension is available for download:

komodo-cfml-0.2.4a0-ko.xpi

As always, comments and follow-up are welcome here or on the Komodo-CFML page.

Atom: First Impressions

I spent a bit of time playing with Atom today, and — although I did go into it with low expectations — I found that it does not suck.

I spent a bit of time today playing with Atom, and it does not suck. I have to admit I went into it with low expectations.

Things I like (in no particular order):

  • a UI that obviously is designed to support largely keyboard-driven interaction (e.g., it is very straightforward to turn on/off soft-wrapping of text, something that I need for whatever I use for my Q&D text editing, as soft-wrap for drafting text = necessary while soft-wrap for any sort of code = worse than bad),
  • a language mode for CFML (thank you, Adam Tuttle) already available,
  • availability of Emmet as a package,
  • a reasonably-polished preferences UI that makes it simple to configure.

Perfect? Not by a long shot. But good enough to convince me that I need to poke a little further before I write it off.

New Dev Boxes

It is time: I’m standing up a couple of new development systems, so I am using Tomcat 8 and Java 8 as the basis for deploying Railo and Adobe ColdFusion 10. It started as smooth sailing, but I ended up dropping back to Tomcat 7 and Java 8.

It is time: I’m standing up a couple of new development systems, so I am going to use Tomcat 8 and Java 8 as the basis for deploying Railo and Adobe ColdFusion 10 on them. This is the first time I’ve done anything with either Tomcat 8 or Java 8 as the base for the application server stack but with Java 7 set for EOL this (I first wrote “next”) year, the timing for moving seemed appropriate.

I have Railo deployed and running without issue on the first of the two systems, and have encountered no issues at all to this point.

I will blog a bit in the near future to describe my approach and a couple of minor Tomcat differences I have found.

Updated 2014-01-02: Well, that didn’t take long to go sideways… I spent several hours this afternoon trying to deploy ColdFusion 10 on Tomcat 8, and so far have been unsuccessful. I can get the WAR to unpack, but the application simply refuses to start with a very non-specific error in the Catalina log file that (I’m guessing here) appears to indicate an incompatibility with Tomcat 8 in ColdFusion 10. More to come, but my next run at this will probably be to drop back a step or two and try deploying on Tomcat 7 and Java 8.

Updated 2014-01-03: Moving forward again. As of this morning, I now have both Railo 4 and ColdFusion 10 deployed against Tomcat 7 and Java 8.

Adobe ColdFusion Docs: A better way?

I’m not a fan of the structure the Adobe ColdFusion documentation team has moved to for documentation for the recent versions of their product. It’s not a problem with the move to a wiki but more of a poor choice in the structure of the documentation with respect to language/product versions. I think there’s a better way.

I’m not a fan of the structure the Adobe ColdFusion (ACF) team has moved to for documentation for the recent versions of their product.

A bit of background

With the recent (late May 2014) release of ACFv11, there are now three versions of ACF in which I have varying degrees of interest:

  • v9: we are in the final stages of moving our last app from a shared v9 server to one of our dedicated v10 servers,
  • v10: our entire dev environment is based on v10, and all of our apps with the noted exception above run on v10 in production, and
  • v11: the recent release we’ve watched from a distance as we weigh whether to continue with ACF in the future or shift to Railo as our CFML engine.

My team has used ColdFusion since its Allaire v4 days, and have historically had multiple versions in play across our development and production environments, so the above situation covering three versions is very typical for us. In fact, having all of our dev and production environments based on a single version of ACF as we (almost) do now represents the first time in at least 10 years we’ve been able to achieve this. I don’t believe we are unique in this: any developer moving between versions of the product (or even considering such a migration) will be working with at least two versions of the language and/or the documentation before and during their migration effort.

In addition, I built and continue to maintain a CFML language mode for ActiveState’s Komodo IDE and Edit editors, providing syntax highlighting and tag/tag attribute completion. The tag/tag attribute completion is specific to each CFML version, allowing the user to designate which version of the language is to be used as the basis for which tags and which attributes are to be provided as options to the user. I rely heavily on version-specific documentation to build each of these version-specific implementations.

The problem with the current wiki approach

In recent versions of ACF up through v9, each version had comprehensive documentation sets available both online and as downloadable PDFs. Each of these documentation sets were separate and distinct, and the online versions made it very straightforward to shift between versions. With v10, there is a downloadable PDF version of the documents (thanks to Adam Cameron for pointing me toward those) but the only references to it are not particularly easy to find (search the wiki for “archive” — how obvious is that if you are looking for v10 documentation?). Googling for “adobe coldfusion 10 documentation” does not yield that set of documents in the first page of results. Further, there does not seem to be an online version of some portions of the v10 (such as the tag/function reference). The current online version of the documentation is maintained as part of a wiki that does not contain discrete sections for different versions of the product or language, and for the most part appears to be focused on v11.

The old version-specific implementation of the online docs has the tremendous benefit to the user of being crystal clear as to what capabilities are available in a given version of the language (e.g., which attributes are available for a given tag, what functions/function arguments are available). If I am working on an app currently running on version “x” of ACF, I typically want to see only the version “x” documentation for that tag.

The current wiki-based documentation set, however, does not have that clear distinction between versions of the product or language. This makes differentiating between versions for tags, attributes, supported attribute values, functions, etc., in terms of what is valid and supported between versions far more challenging and error-prone than in previous versions. If I care about the v10 implementation of the cfzip tag, for instance, I have to either use the off-line version of the docs or make sure I look at the “history” portion of the relevant tag page and then mentally remove the new attributes added for v11 (“password” and “encryptionalgorithm”, in this particular case) as I scan down through the attribute documentation — particularly given that there is nothing within the description of the individual attributes indicating their recent addition in v11 (and in the case of the “password” attribute, it seems to be missing altogether from the attribute list).

A better approach?

It seems to me that a better approach would be for separate, discrete version-specific sections within the wiki. The language reference — along with the supporting documents identifying additions, removals, and deprecations — is one example of where this would make the documentation much easier to use. The v10 portion of the reference would always be specific to v10 and would not (should not?) need to contain any v11 content. The v11 portion of the reference would presumably start as a clone of the v10 portion of the documentation, and could evolve along with the language as v11 was developed. As work on v12 is started, the v11 portion would be cloned as a draft and evolve independently from the sections covering previous versions.

The current wiki approach is likely to get more and more unwieldy as additional versions of the product and the language are covered within the current wiki structure. Take the page listing deprecations and removals as an example. Besides being in drastic need of updates as of this writing for completeness and currency with v11, this page — based on its current structure — will get more and more unwieldy as additional versions have to be covered: more rows to cover features being deprecated or removed, and more columns for subsequent versions? The current approach just does not seem to scale for pages such as this.

Note that I am not taking issue with the use of a CMS or wiki for the documentation itself as much as what I see as a poor decision of how to structure the documentation within the tool the ACF team selected.

Finding documentation for earlier, but still-supported, versions of a product should not be difficult but in this case it is getting harder. I’d like to believe the ACF documentation team will recognize this and restructure the documentation set before it collapses under its own weight and degenerates even further in terms of being usable and useful.

And the off-line docs?

The current wiki structure — which seems to be focused mostly on the current language version — also raises the question for me as to whether a similar set of downloadable v11 references will be made available now that the product is available or as the wiki gets refocused on v12 (presumably in the near future, immediately after all of the existing v9/10/11 bugs have been resolved). That’s a separate but important and relevant question. I hope they do continue making that format available, as those downloadable PDFs have repeatedly proven valuable for me and my team at various times.