Adding ModelGlue’s event API to ColdFusion Builder’s code insight

For the last year or so, all of my ColdFusion development projects have been built using the Model-Glue MVC framework. Over time, you get to where you know the most commonly used methods that are used to interact with the framework by heart. Sometimes there are lesser-used methods that you have to go look up. All the time (for me at least) I’m trying to find a way to write code faster and with less errors.

ColdFusion Builder has done a very nice job of providing code insight for ColdFusion tags, functions and CFC methods. This is especially true if you have a server configured in the “Servers” panel and mapped to your CF Builder project as it then will provide code insight for your own CFCs that you create on the page. However, when using Model-Glue, the “event” object is created for you and is always there. Because it’s not explicitly created on the page, CF Builder can’t provide code insight when you need to interact with it. However, it only takes a couple of settings in your project to make CF Builder aware of the event object and start providing help for it.

Here’s the process:

  1. Right click on your project and choosing “Properties”.
  2. In the left pane of the window that comes up, click on “ColdFusion Variable Mappings”.
  3. On the right side, click the “New” button and enter the following values into the boxes
    • Variable Name: event
    • Mapped To: html.ModelGlue.gesture.eventrequest.EventContext
  4. Press the “New” button and enter the following values into the boxes
    • Variable Name: arguments.event
    • Mapped To: html.ModelGlue.gesture.eventrequest.EventContext
  5. Press the Apply button then the OK button

    * Note that the value in the “Mapped To” box is the actual dot-notated path to the EventContext.cfc file from your CF Builder project root. I happen to have my webroot files in a folder named “html” under the project root (see screenshot #1 below).

    Once you have those settings saved, any time you type “event.” or “arguments.event.” you’ll get the list of methods contained in the Event object. Of course, this doesn’t only work with Model-Glue. Any CFC that you regularly use the same name with can be configured this same way.

    I’ve attached some screenshots for reference. If you have any questions or something isn’t working, feel free to ping me.

Followup to my CFMeetup development environment presentation

Last week I gave a presentation to the CFMeetup group showing how I use Eclipse and Tomcat to develop CFML applications across any of the current CFML engines (if you missed it and are interested, here is the link to the meeting recording). One of the aspects of my environment that we didn’t have time to discuss is the link between the Apache web server and Tomcat. Some people will accurately point out that you don’t really need the Apache web server since Tomcat has a very fast built-in server that you can easily configure to run on port 80 rather than the default 8080. I personally like to try to keep things as close to production configurations as possible so I use the Apache web server when developing locally.

Read More

Configure FusionDebug 3 Beta for use with Railo 3.1 on Tomcat

For the past couple of months, I’ve been running my CFML server engines (yes engines, plural) on top of Tomcat on my local development environment. This offers me, as an independent developer that works on a number of different client projects, a great deal of flexibility in matching a particular client’s production configuration. Also lately, I’ve been working on a couple of projects using Railo 3.1 as well as a project for a client that still uses CFMX 7. One of the things that I really missed when not developing with ColdFusion 8 is the step debugger that ships with CF8. I’d used FusionDebug some time ago with CFMX 7 when I was running it on top of JRun 4 but had never gotten around to getting it configured under my current, Tomcat-based setup. Until tonight that is.

I ran into a situation while working on a MachII application running on Railo 3.1 where I REALLY need to see what was going on with the various variable scopes during the request cycle, so I decided tonight to see if I could get FusionDebug 3 Beta up and running with Railo and Tomcat.

Read More

Configuring ColdFusion applications on Tomcat with Apache web server

In my last post I mentioned that I had been toying around with using Tomcat as the only servlet container to deploy all my ColdFusion applications to, regardless of what ColdFusion engine you needed to use for a specific project. My goal in trying to get this working was actually 3-fold:

  1. Learn more about how standard JEE servlet containers worked and how to configure them
  2. Remove my dependence on JRun as it is not under active development any more
  3. Be able to have one central place to start/stop each application’s instance as I switch between client projects

So far, I’m 2 for 3 on those goals. What follows is a brief history of what I did in the current iteration, what works well and what I’m still missing to have what I believe is the perfect development environment (at least for my situation). The steps I took here are based on my experiments using Mac OS X, but should be fairly close for Windows users.

Read More

To .WAR or not to .WAR?

A week or so ago, Matt Woodward posted a blog entry detailing how to install Railo and Open BlueDragon on Tomcat. Since then I’ve been experimenting with installing not only Railo and Open BlueDragon into Tomcat, but Adobe ColdFusion 8 and MX 7 as well. I’m trying to determine if this configuration is better for me as a consultant that works on a variety of customer projects on various CFML engines. I’ll leave that discussion for a future post as I’ve not decided quite yet what I think.

One thing that this experimenting has me thinking a lot about, however, is the “organization” of the code base for our projects. Here’s the question that I’m working through in my head at the moment. Should we be organizing our application code so that it can be packaged up in a WAR file–whether or not we ever expect to deploy our application as a WAR? I realize that everyone has a different “pet” way they like to organize their project code–I myself have been using a certain standard folder structure that I like for a couple years now. However, my folder structure would not work if you wanted to take my application and package it up as a WAR file that included a specific CFML engine.

As an example, I have been including a /conf directory (for framework XML config files etc) in my project structure that is at the same level as my /html directory (this functions as my web root). Most of us have most likely heard people advocating this structure because it puts the XML files outside of the web root and thereby protects people from being able to browse our XML config files directly to view sensitive configuration data for our applications. This particular organization would break since the context root as defined in the WAR file needs to be the directory that includes my web files (/html in this case). So, I would need to reorganize my project so that any files that need to be deployed via the WAR file would reside under my /html folder.

I’m VERY new to the whole Java servlet container scene, and therefore I obviously don’t know what is possible in the Tomcat configuration files that might address this issue. I suppose it might be possible to use the configuration options in the web.xml or context.xml to modify your project structure, but right now I’m not familiar with how to get this accomplished.

What do most shops do when developing a new application that could be deployed on any given CFML engine? Should we be trying to use the standard Java WAR method or continue to use the methods we’ve all been using to now deploying individual files to a web root on a server?

I’m leaning toward rethinking my project organization to allow deployment via WAR files and using some sort of process in an Ant build script to include a specific runtime depending on what CFML engine is required for the project (or none at all if it is to be deployed as simply files under a web root). Any thoughts or suggestions?