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.)

Friday, August 23, 2002

Finding CFMX Admin Configuration Data

Some may have noticed that the CFMX Administrator no longer stores its configuration info (such as settings, datsources, verity collections) in the registry. If you've got tools that expect to find the info there, you'll run into trouble.

The good news is that most of that info is now simply stored as wddx packets in xml files, stored in the cfusionmx\lib directory (such as neo-query.xml and neo-verity.xml). Don't mind the neo reference. They just didn't change that in the final release.

Now all you need to do is learn how to process the xml, or more particularly the wddx packets. CFMX's new XML features should help. I highly recommend David Gassner's 3-part series of articles in the June, July, and August CFDJ for more help on that.

Just as an aside, some may notice that there's also info about your datasources in \CFusionMX\runtime\servers\default\SERVER-INF\jrun-resources.xml. It's not clear to me what the difference is between the info stored in the two places.

New Possibilities for Session and Client Variable Handling in CFMX

Back in late June I wrote a few blog entries about some new features in CFMX for working with session variables. Since then, I've written an article in the August CFDJ, "New Possibilities for Session and Client Variable Handling in CFMX". You can read it, and all my articles, online at http://www.systemanage.com/cff/articles.cfm.

Whether you're using CFMX or not, there may be things that you learn in the article that may surprise you about how session and client variables really work.

Are you thinking, "I already know about J2EE session variables"? That's not what this is all about. It is indeed one of the three new features, but the other two aren't dependent on that one and are of value to any CF developer. One of them doesn't even require any change to your code to obtain substantial benefits. The features covered are:

The New URLSessionFormat() Function
Using a UUID for CFTOKEN
Using J2EE Session Variables

Server-side redirects in CFMX

Did you know that CFLOCATION is a client-side redirect? Do you know what that means, and what the cost is?

Did you know that CFMX has added a server-side redirect--in getpagecontext().forward()? Do you know that that means, and what the benefit is?

Did you know that I've written a custom tag, CF_FORWARD, to encapsulate calling this new function and handling some of the common challenges of working with it?

All this and more are explained in my June 2002 CFDJ article, "New Possibility in CFMX: Server-side Redirects". You can read it, and all my articles, online at http://www.systemanage.com/cff/articles.cfm.

Thursday, August 22, 2002

Series of Articles on MVC and CF: and a proposed new design approach, MVCF

If you're interested in the subject of applying MVC design approaches to CFMX, you should check out http://www.benorama.com/coldfusion/. Even if you're new to the idea, it's worth a read to get you thinking.

That's not Ben Forta but Ben(oit) Hediard, of France, who has documented via a series of 10 articles (at that site) his offering of a way to leverage features of CFMX to do MVC-style development. He uses CFCs, WDDX, CFIMPORT of CF custom tags, UDFs, and a few other features that might intrigue many. He's even now come to refer to it as MVCF, and is proposing the ideas as an alternative framework.

I know that alone should peak the interest of many (one man's framework is another man's call to battle). I'd certainly look forward to comments from those with both more experience with the approaches he uses (to see if he says anything you'd argue against) and those with less experience with them (to see if his presentation gives you useful ideas to explore).

Pardon his grammar, as he's not a native speaker. (Actually, he quickly accepted some grammar and typo suggestions I offered to improve things about the first few pages I had read when he first posted it.) I've shared some additional observations of how to make the presentation even more useful, especially to relative newcomers to CFMX and/or MVC and some of the other approaches he's demonstrating. In a couple of places he leaves some things unsaid presuming that you're following it all. But it's definitely something that many people can take as a ball to run with, as is. Some very interesting application of things in CFMX.