Saturday, August 24, 2002

Updated Precompile.bat file--compiles outside the default webroot

(After reading this to get the full explanation of things, see a couple of minor further updates above.)

I'm very happy to report an upgraded version of the precompile.bat file that I mentioned in a previous June post. This updated version successfully compiles code outside the default webroot, and it doesn't require you to jump through hoops to get that to work--as some other alternatives to that original file did.

The updated code is:


set MX_INSTALL=c:\cfusionMX
set PATH=%MX_INSTALL%\runtime\bin;%PATH%
java -classpath %MX_INSTALL%\lib\cfusion.jar
    coldfusion.tools.Compiler -webroot %1 -webinf %MX_INSTALL%\wwwroot\WEB-INF %1


That code above has been superceded by this, which I explained in my 12/10 entry:

set MX_INSTALL=c:\CFusionMX
set PATH=%MX_INSTALL%\runtime\bin;%MX_INSTALL%\runtime\jre\bin;%PATH%
java -classpath %MX_INSTALL%\lib\cfusion.jar coldfusion.tools.Compiler
    -webroot %1 -webinf %MX_INSTALL%\wwwroot\WEB-INF %1

The rest of this note refers to the struck out entry above, but the info may still be useful.

What's different from the June post? Notice the highlighted -webinf directive. That's one missing link that was keeping it from working well against code in directories other than cfusionmx\wwwroot (or inetpub\wwwroot if working with IIS). Thanks to Harry Klein of CONTENS Software in Germany for that clue. The other is that the -webroot directive ought to point not at the "real" webroot for CFMX but instead at the directory containing the code to be compiled. At least, this is what I've found is necessary to compile code outside the normal webroot.

Again, that's just 3 lines of code (2 sets and a java command line) that you'd save in a file called precompile.bat. Be sure to set the first line to the location of your cfmx install directory. Again, it doesn't matter if your code is located elsewhere. Store the batch file anywhere you'd like, and then call it from the dos command line with, for instance:

Precompile c:\cfusionmx\wwwroot\mydir

Or

Precompile d:\mydir

Notice that the second example is compiling code outside the default cfusion\wwwroot (or inetpub\wwwroot for IIS users). That's now possible with this version of the batch file. For more info on setting up CFMX to execute code in directories outside the default webroot, see my entry of August 15.

This version of the batch file will compile any directory of CF templates, as long as you specify the complete path to the file. The old version worked with relative paths (and also would allow multiple paths to be specified), but to solve the problem of being able to compile code outside the default webroot, it takes just one and it must be a complete path.

And though I didn't mention it in the previous post, this precompile.bat file does allow you to specify just a single file name. It may be useful to some to be able to compile just a single file, rather than an entire directory and its subdirectories. You can do that, too, as in:

Precompile c:\cfusionmx\wwwroot\myfile.cfm

I've not been able to get it to accept a pattern, at least not in this simple 3 line version of the batch file.

Update: I've since gone on to discuss all this further in 2 articles in the October and November CFDJ. You can find links to there for all my articles at www.systemanage.com/cff/articles.cfm)

BTW, I'd asked if anyone could tell me how to do this in Unix environments, and I have been given an answer. See blog entry above.

Oh, and like the previous version, this one automatically compiles all code in the named directory and any subdirectories. If anyone can figure out how to stop it doing that, I'd be interested. I'd prefer a solution controlled by directives to the compiler, rather than creation of a complex batch file. I could certainly see making the batch file more robust and more powerful, but it's kind of nice to have such a simple 3 line file.

(One last thing: if you don't know how to get to the command line in Windows systems, see my entry of Friday Sept 20, 2002.)

No comments: