epiphantastic » ColdFusion

Problem Installing ColdFusion 8 on Snow Leopard

Thomas — Wed, 13 Apr 2011 19:20:37 +0000

I ran into a problem trying to install ColdFusion 8 on my MacBook Pro running Snow Leopard. I honestly don’t know the what the exact problem is, but from what I can gather, it has to do with Java and the crappy InstallAnywhere installer used for CF 8. To give credit where credit is due, the solution is taken from this site: http://www.doyourself.org/windows-2/786-install-coldfusion-8-on-snow-leopard/

The steps are simple:

Open a Terminal
cd “Downloads/ColdFusion Installer 8.app/Contents/Resources/Java” (modify to fit the name/path of your installer file)
java -cp ./IAClasses.zip:Execute.zip:installscript.zip:. com.zerog.ia.installer.Main
Installer should launch, just install normally

Doing this allowed me to get through the install. I did it with CF 8 64 bit, but I checked an the 32 bit installer wouldn’t run for me either, so maybe this would work in that case too.

Lightwire Tutorial 2: AOP

Thomas — Mon, 15 Mar 2010 14:03:08 +0000

Now that I’ve gone over the basics of Lightwire as far as creating bean and injecting dependencies go, let’s get into some Aspect Oriented Programming (AOP). AOP is about addressing the separation of cross-cutting concerns from the main application functionality. Yeah, I know, the first time I read this, it came through as “blah blah blah [jargon here] blah blah blah.” So to simplify, cross-cutting concern just means some functionality that can apply to many parts of an application. The examples you’ll likely see over and over for this (and rightly so) are logging and security. Suppose you have a bunch of components/beans and you want to log method calls for several/all the methods in those beans. You could do something like this in a method:

Now think of having to do it for 75 beans with an average of 7 methods in each. Are you feeling the pain? Or what if you suddenly needed to apply security to certain parts of a site running on an MVC framework. Imagine your controller:

Now think about adding that cfif for all the methods that pertain to Area 51. Sounds like a great way to lose your sanity. Enter AOP! AOP will allow you to do all these things and avoid that stream of curses that would undoubtedly result from your boss telling you “Listen Bob, I have this project I need you to work on…” For instance, let’s take a look at the first scenario using Lightwire and AOP. In the code below, assume that the Logger.cfc file is exactly the same as the one above.



	
		
	

	
		
		.....
	




	
		

		

		
	

	
		
		
		

		
	




	
		
		// Call the base init() method to set sensible defaults. Do NOT remove this.
		Super.init();

		// OPTIONAL: Set lazy loading: true or false. If true, Singletons will only be created when requested. If false, they will all be created when
		//LightWire is first initialized. Default if you don't set: LazyLoad = true.
		setLazyLoad("false");

		// BEAN DEFINITIONS (see top of bean for instructions)
		addSingleton("cfcPath.Controller");
		addSingleton("cfcPath.Logger");
		addSingleton("cfcPath.LogAdvice");

		// Depency Injection
		addConstructorDependency("LogAdvice", "Logger");

		// AOP Advice
		addBeforeAdvice("Controller", "Logger", "doSomething");

As you can see, the logging code has been completely removed from the original Controller.cfc file. The Lightwire config file is fairly straightforward. The Controller bean, Logger bean, and a new LoggerAdvice bean get defined with addSingleton() calls. Once defined, a Before advice is used to tell Lightwire that you want method “before” (it’s the default method for Before advice) from bean “Logger” to run before the method “doSomething” in bean “Controller” when it is called. Simple, right? For this one case, it can seem like overkill, but if you have a lot of logging to do, it’ll save you a lot of time. Note that if you wanted to log every function call in the Controller bean, you could just put “*” as the third argument instead of “doSomething”, and you can also ue a comma-delimited list of functions. If there were more beans you needed to do logging for, you would just need to add an addBeforeAdvice() call for that other bean. This may seem like a problem if you have a lot of beans, but thanks to the programmatic nature of the Lightwire configuration, it’s usually easy to loop through all the CFCs in a directory, add a singleton for each, and add the advice for each. Also, while I think the LoggerAdvice bean is recommended in this case to keep the generic Logger functionality (you may be using it for other things than logging method calls), you could technically only have a Logger bean and define a before() method in it, eliminating the need for the LoggerAdvice.

Now, let’s move on to the second example. Here’s how you could implement the security using AOP and an Around advice:



	
		
	

	
		
		.....
	




	
		

		

		
	

	
		

		
			
		
	




	
		
		// Call the base init() method to set sensible defaults. Do NOT remove this.
		Super.init();

		// OPTIONAL: Set lazy loading: true or false. If true, Singletons will only be created when requested. If false, they will all be created when
		//LightWire is first initialized. Default if you don't set: LazyLoad = true.
		setLazyLoad("false");

		// BEAN DEFINITIONS (see top of bean for instructions)
		addSingleton("cfcPath.Controller");
		addSingleton("cfcPath.Security");
		addSingleton("cfcPath.SecurityAdvice");

		// Depency Injection
		addConstructorDependency("SecurityAdvice", "Security");

		// AOP Advice
		addAroundAdvice("Controller", "Security", "uncoverKennedyAssassinationPlot");

This case is similar to the first, except this time we’re using an Around advice. Around advice gives you more complete control over method execution, it’s kind of a Before and After advice rolled into one. The AdviceDispatcher argument it receives allows you to retrieve info about the method and bean that is being advised, as well as control the timing of the execution of the original method. You could even decide, depending on logic, that you don’t want to execute that method at all. And again, if you need to apply security to many different parts of your app, it’s easy to use this and apply it to multiple beans/method in a generic way.

As a side note, it’s worth mentioning that while I use Lightwire because it’s the project I’m contributing to, all this is applicable to ColdSpring, which offers the same types of advice. The difference is that you’d have to define your beans, dependencies, and advices in XML and if I remember correctly your beans have to extend certain components. But it’ll get the same job done. Also, it’s worth noting that AOP is not yet in the main distribution of Lightwire (see my previous post on AOP in Lightwire), it’s only available here until it’s further vetted. Feel free to download it from the Download section and give it a try. Any feedback is very appreciated.

I hope that from these examples you’re able to see both the power and convenience that AOP can provide you with, and how to use Lightwire to achieve those results.

Lightwire Tutorial 1: The Basics

Thomas — Fri, 12 Mar 2010 17:38:09 +0000

Following up on my last post regarding Lightwire Aspect Oriented Programming (AOP), I thought I’d write up some tutorials to help people get familiaried with Lightwire itself, since I didn’t see a ton of info around. The harder part is actually getting comfortable with the concepts of dependency injection and AOP. Once you got those figured out, Lightwire is stupidly easy to use.

In this post, I’ll cover the concept of dependency injection and leave AOP for another post. Dependency injection is basically a way to ensure that your code is more loosely coupled. As it turns out, it can also make it a heck of a lot easier to use your objects. As an example, I’ll use something simple that will hopefully demonstrate the concept well. I’m going to take a simple service bean (a bean is just a CFC) and a logger bean and show different ways to make them work together. The service bean could do anything, its functionality is irrelevant to this example.

The above illustrates highly coupled components. What’s wrong with it? Technically speaking, nothing. It won’t throw errors or anything (unless I screwed up something!) But the two components are tightly coupled. Imagine if you want to change the class you use for logging? In this simple scenario, it’s pretty simple, all you need to do is change that one call, but what if you have 100 service beans and all of them use the Logger bean? It becomes a bit more painful, right? OK, OK, you could do a Find/Replace in your IDE, but you catch my drift. The other problem is that you will need to manually instantiate the logger bean in every component, which is tedious and violates the DRY principle. Finally, you sometimes want a bean to be a singleton, meaning there’s only one instance of it for the entire application. You need something to manage that.

Here’s another way to go about it (the logger component stays the same so I won’t repeat it here, assume it’s the same as the one above):

Using the above, things are a little better. The Service bean receives the Logger bean when created and doesn’t have to worry about how it gets instantiated. However, you’re still left with the tedious task of creating the factory, instantiating the Logger manually, etc. Imagine if you wanted the logger to behave similarly. You’d have to create a factory for it to. And imagine if the logger object had dependencies of its own. You can see how this can get really ugly. That’s when a dependency framework comes to the rescue. Here’s how you would do things with lightwire:

In the example above, assume that Logger.cfc is the same as the first example and Service.cfc is the same as the second example. With that out of the way, here’s what’s happening in the above. In the configuration bean, you’re giving Lightwire the definition for your beans. The addSingleton() function is used to define a singleton bean, and you could use addTransient() in the same way to define a transient bean. Within that function call, you specify the path of the component in the first argument and the name of the bean as the second. If the name of the bean is the same as the last part of the path, you don’t need to specify it. You then use the addConstructorDependency() to wire the beans together. The first argument is the bean you want to inject something into, the second is the bean to inject. Then the index.cfm file shows how to start Lightwire and get a bean from it. So the getBean() call basically retrieves a bean based on the configuration above. So behind the scene, something is happening to do createObject(“component”, “cfcPath.Service”).init(createObject(“component”, “cfcPath.Logger”).init()); without you having to type all that. Imagine how useful that is when you have tons of beans with lots of dependencies, that are reused in many other beans. Priceless. Note that since we defined the beans as singletons Lightwire will only instantiate them once in its lifetime. So if you store Lightwire in a persistent scope, like the application scope, your beans will only get created once, saving you the overhead of creating them over and over.

There are 3 ways to inject beans in Lightwire. The first is the one described above, using a constructor dependency. In that case, you add an argument to your bean’s init() function matching the name of the bean to be injected (or you can specify a different name as the third argument of the addConstructorDependency() function). A second way is a setter injection. For a setter injection, you would use addSetterDependency() function. The arguments are the same as for the constructor function, but to get the bean injected you need to define a method in the receiving bean named “set[BeanName]“. Finally, there’s mixin injection. You can add a mixin dependency by using the addMixinDependency() function, which works exactly like the other two, the difference is you don’t need to do anything in the receiving bean. The injection will be done behind the scenes and you don’t have to worry about a thing.

How do you know which injection type to use? It really depends. If you have two beans that both depend on each other, you can’t use constructor dependency, otherwise you’ll run into a circular reference problem. So you can use setter or mixin dependencies in those cases. If you need to use the injected bean in the init() method of the receiving bean, you’ll probably want to use constructor injection. Then it’s down to preference. Some people don’t like mixin injection because they feel it hides part of the implementation and can be confusing to an outsider looking at your application. But I find it invaluable, saves me from adding all those constructor arguments or setter methods. When I have a bean I want to inject pretty much everywhere (like a Utility bean, for example), I usually use mixin injection.

You can also inject regular properties using addConstructorProperty(), addSetterProperty(), and addMixinProperty(). All those take 3 arguments, the name of the bean, the name of the property, and the value of the property.

So this ought to cover the basics of DI and how to use Lightwire for that purpose. Stay tuned for a post on Lightwire and AOP (I’ve already done one, but I’m gonna try to make one that’s actually clear!)

Aspect Oriented Programming (AOP) with Lightwire

Thomas — Fri, 12 Mar 2010 06:02:29 +0000

I’m a big fan of Peter Bell’s Lightwire framework. I’ve been using it for quite a while for dependency injection and I love it. However, it’s been lacking a key feature that ColdSpring has: Aspect Oriented Programming (AOP). No more. I’ve taken some time to add some AOP magic to Lightwire and although I haven’t been able to test much yet, it’s looking pretty good so far.

First things first, I gotta give much credit to the developers of ColdSpring. My implementation was very much inspired by their work and made it that much easier to get things done. For users of ColdSpring, things will look rather familiar, I’ve implemented Before, After, Around, and Exception advices in Lightwire, all of which are supported by ColdSprings, albeit some with slightly different names.

For users of Lightwire, AOP is implemented with the same simplicity as the rest of the framework and is a breeze to use. Advices are defined in the configuration bean in a similar way as beans. There is a method for each type of advice: addBeforeAdvice(), addAfterAdvice(), addAroundAdvice(), and addExceptionAdvice(). The arguments for these four methods are the same, so I’m just going to show addBeforeAdvice():

addBeforeAdvice(
	beanName,	// The name of a Lightwire bean that you want to give advice to
	adviceBeanName,	// The name of a Lightwire bean that provides advice
	[methods],	// Optional, methods that the advice applies to; defaults to *, which means all, can be a comma delimited list of method names
	[adviceMethod]	// Optional, name of the advice method, which defaults to the advice type (before, after, around, or exception) if not specified
);

Note that neither of the beans specified above need to extend anything. They can be any bean, any class, extending anything else you want. Now, let’s take a look at what parameters the advice bean methods should receive. Note that I’m going to use the default method names, but you can set the advice method to whatever you want using the optional adviceMethod argument.

before(
	method,	// The method that triggered the advice
	args,	// The arguments passed into the method (struct)
	target	// The bean that contains the method that triggered the advice
);

after(
	method,		// The method that triggered the advice
	args,		// The arguments passed into the method (struct)
	target,		// The bean that contains the method that triggered the advice
	[returnVal]	// Will return a value if the triggering function returned something
);

around(
	AdviceDispatcher // An AdviceDispatcher object, which will be further discussed below
);

exception(
	method,	// The method that triggered the advice
	args,	// The arguments passed into the method (struct)
	target,	// The bean that contains the method that triggered the advice
	error	// The cfcatch struct for the error
);

While you are not required to define the arguments (you might not need one or more), if you do define them be sure to spell them right because they are passed as named arguments, not numbered.

Now, the around() method is special because it receives a single object, AdviceDispatcher, which is essentially the same as the MethodInvocation object in ColdSpring. This object gives you full control over what will happen with your method call. Within your around device, you can trigger the target method execution by calling the run() method of the AdviceDispatcher object. Beyond that, you can put any code you want around it, to define code to run before and after. Your code can also make it so the method will not run in certain situations, all you have to do is create a situation where the AdviceDispatcher.run() method does not run. Here is the definition of the AdviceDispatcher object:

lighwire.aop.AdviceDispatcher
METHOD		RETURN TYPE	DESCRIPTION
run()		void		Executes the target method
getTarget()	object		Returns the target bean object
getMethod()	string		The name of the target method
getArguments()	struct		The arguments passed to the target method

That’s it! This is pretty much all you need to know to do AOP with Lightwire. Now I do realize that this article assumes prior knowledge of Lightwire and AOP, so I’m hoping to blog some tutorials on both of those topics to make things clearer for those just getting started with those.

I’ve been talking with Peter Bell and if my changes prove to be any good, which I hope they will, they could eventually make it into the core product on riaforge. For now, you can download my modified Lightwire by clicking the link at the bottom. I’ve included an aopSample folder where you can see some tests. They’re not the best and just output text, but it’s better than nothing for now. You can unzip the folder in your webroot, or you can unzip it anywhere on your web server and modify the component paths in the aopSample/index.cfm file. I’ve been testing this on CF 8, IIS, so if you run into problems and are running on a different platform let me know so I can get them sorted out.

DOWNLOAD LIGHTWIRE WITH AOP

Arbitrary runtime constructor dependencies in Lightwire

Thomas — Sat, 06 Mar 2010 14:47:28 +0000

I love Lightwire for dependency injection, it’s lightweight, it’s not XML based, and allows for mixins which saves me from having to constantly add constructor properties or setters. However, I was recently confronted with a problem. When using Lightwire for transient beans, I often found myself wanting to inject dependencies, but also pass in some properties/dependencies at runtime (for example, some data somebody entered in a form). Now, an obvious way to do this would be to define the bean without that dependency, create a setter for it, and then add whatever you need to the bean using that. Somehow, it felt like kind of a roundabout way of doing it, so I figured I’d look for a way to be able to do it at the time of bean invocation. In terms of code, here’s what I was looking for:

myBean = application.lightwire.getBean("myBean", form.runTimeData, form.moreData);

INSTEAD OF

myBean = application.lightwire.getBean("myBean");
myBean.setRuntimeData(form.runTimeData);
myBean.setMoreData(form.moreData);

Note that you could also do the above with one setter that would set all the runtime data you want at once. Still, it’s an extra call, and that just bothers me to no end! So after some modifications to the Lightwire code I was almost able to do what I wanted, with a small caveat. I wasn’t able to use numbered arguments, had to settle for named arguments for now (though I’m still working on it). So right now I’m able to do this:

myBean = application.lightwire.getBean(
	objectName="myBean",
	runTimeData=form.runTimeData,
	moreData=form.moreData
);

I’m not 100% happy with it because I’d like to get it working with numbered argument and avoid all that typing, but the arguments/argumentCollection object is a weird one and I haven’t been able to swing that yet. Hoping I’ll come up with some sort of solution eventually (if anybody has some insights in the Java internals of argumentCollection and how to manipulate that, I’m all ears). But for now this works for me.

I’m interested in knowing if anybody else would find this feature useful, or if for any reason this would be bad practice and maybe I’m going about things all wrong. Again, I know it’s kind of a small nitpicky thing, but when you’re coding all day, small details make a big difference!

Making ColdFusion report fields stretch without messing everything up

Thomas — Tue, 24 Apr 2007 18:08:21 +0000

The ColdFusion Report Builder was a welcome addition to CF, allowing for report generation without using third-party software like Crystal Reports. The problem with it is that documentation and examples are sparse. And the CFREPORT site doesn’t seem to have a lot of activity lately (in all fairness, I did not contact the site owner, maybe he’d have a solution for me). Granted, it’s not really that complicated to pick up, but there are some cases that leave you scratching your head. I recently ran into one such case.

Basically, the report builder allows you to put some fields on your report and you can make them a certain size. But what if you have text of variable size and you’re not sure how long it’ll be? No problem, you can just set it to whatever width you want and then set the “Stretch With Overflow” field to true. That way when the text is too long to fit within the pre-defined width it’ll wrap to the next line. That’ll solve all your problems, right? Nope…

This solution will work if your report is a simple table, with a single row of fields put one next to the other. If you have a field that requires more space, the text will wrap and push down thenext record. But what if you have something like the following?

Suppose the Office field got long and you set its “Stretch With Overflow” property to true, guess what would happen? Yeah, the text would wrap alright, but it wouldn’t push the stuff below it down, instead it would overlap it, and that’s obviously not good. I searched around and didn’t really find an answer to my problem. So either I didn’t search enough and wasted my time with a hack when there’s a built-in solution, or else I’m very clever and came up with a brilliant hack. I hope the latter is true!

I figured the way to make things stretch properly would be to put things in different bands. But you can’t randomly insert bands. So to get an extra band, we need a hack. I did it using groups. Basically, whenever you add a group you get a new band for that group. So my idea was to add groups on a field that is unique. That way you get extra bands but they actually aren’t grouping anything. I just used the primary key of my records as the group by field. And to be able to get more bands, I modified my query and to something like this:

SELECT
	JournalID,
	JournalID AS StretchHack1,
	JournalID AS StretchHack2,
	...
FROM Journals

Then you go under “Report > Group Management” and use those fields for Groups. You can put in as many groups as you need bands and then break down your fields/labels into the different bands. Here’s the result for my example:

I set the “Stretch With Overflow” property to true for Office, Contacts, Categories, and text. Because they are all in separate bands, if their content is too long to fit on one line it’ll wrap to the next line and push down the content below. Neat huh?

I’m sure this is not a bulletproof solution and there are certain types of layouts where this might either not work or be a real pain in the ass to use. But I think it should come in handy in cases resembling the one I illustrated above.

JSON schemas/validation with CFJSON

Thomas — Sun, 25 Mar 2007 22:12:00 +0000

I’ve made it no secret that I’m not a fan of XML. However, one of the advantages of XML that is constantly brought up is the ability to validate XML documentes using an XML Schema or DTD. I haven’t had much use for them myself, but seeing as many people consider this important, I figured there was no reason the same couldn’t be done in JSON. So I came up with a format for a JSON schema file (written in JSON, of course) and added a function to the CFJSON library to validate a JSON document based on a schema.

While I don’t have docs written for this, it’s pretty self-explanatory. Here’s an example of a schema that shows pretty much all the features I’ve put in it so far:

{
   type: "struct",
   keys: ["title","body","categories","start_date","active"],
   items: {
      title: {
         type: "string", maxlength: 20, minlength: 8
      },
      body: {
         type: "string", minlength: 1
      },
      categories: {
         type: "array",
         minlength: 1,
         maxlength: 4,
         items: {
            type: "struct",
            items: {
               id: {
                  type: "number", min:6, max:10
               },
               name: {
                  type: "string"
               }
            }
         }
      },
      start_date: {
         type: "date", mask: "mm-dd-yyyy"
      },
      active: {
         type: "boolean"
      }
   }
}

In a nutshell, your schema is always an object/struct and it must always have a “type” key set. Then you go on nesting more definitions under the “items” key if you have more complex data types like structs or arrays. The valid types right now are “struct”, “array”, “date”, “number”, “boolean”, and “string”. Each of these data types have some additional options, which are explained below.

struct
For a type “struct, you have two additional keys you can add. The first is “keys”, in which you can provide an array of the keys that this structure MUST have. The second is “items”, which is a structure with keys for each structure key you want to add validation rules for. The “keys” and “items” values are both optional. You can specify an array of keys without providing “items” and vice-versa.

array
An “array” type can take 3 additional parameters, “minlength”, “maxlength”, and “items”. The first two are pretty self-explanatory, they check for a certain array length. The last is similar to the “struct” type’s “items” key, except inside that structure you do not list validation individually for keys since arrays are just numeric. So you simply put in the structure you want for all the items in the array.

date
The only option for the “date” struck type is “mask”. In it you can specify a date mask that you want the date to conform to. The possible masks are the same as the ones used by ColdFusion’s DateFormat function, although this could change because JSON is a universal format not restricted to CF.

number
A “number” type provides additional options of “min” and “max”, which allows you to specify minimum and maximum values for a number. Note that right now the “number” type allows for floats too, this will eventually be updated to allow for validating for integers, floats, unsigned numbers, etc.

boolean
The boolean type has no additonal options, although eventually it’ll probably allow for choosing what can be considered a valid boolean.

string
The “string” type can specify a “maxlength” and “minlength” option that will make sure the string is not longer or shorter than the values specified. Note that the “string” type will actually accept booleans and numbers. Right now I’m not seeing a way around it given the way I implemented things, and I’m not sure it’s really a big deal.

After defining the JSON schema standard I added a validate() function to CFJSON that validates a JSON document based on a schema conforming to the format described above. I also made a small example, creating a JSON document that conforms to the schema above and running the validate function against it. There’s a link to download the example below, all you have to do is change some values in the document or in the schema to see the validation working. There are a few more options that are probably easy to figure out looking at the code, such as the “errorVar” and “stopOnError” arguments. If anybody has any feedback on this I’d love to hear it.

DOWNLOAD CFJSON DOCUMENT VALIDATION EXAMPLE (includes the latest CFJSON)
FIND OUT MORE ABOUT CFJSON

Suppressing whitespace in ColdFusion

Thomas — Sat, 17 Mar 2007 01:10:01 +0000

One of the things about ColdFusion that I don’t like so much is its inability to conveniently suppress whitespace. It’s ridiculous, there are like 3 million tags/attributes/options that are related to whitespace, I seem to discover a new one all the time and it invariably fails to do what I want. First, there’s . The result is pretty straightforward, it kills all output found in between it. Then there’s . That supposedly suppresses things that aren’t inside of tags, but my experience has shown that it doesn’t pick up everything. Then there’s , which I never use, but I tried it recently for something and it was useless. Plus from what I read it’s the worse performance-wise.

Besides the tags, you can set output=”no” on both your and tags, and it’s often necessary to do so. Finally, there’s an option in the Settings section of the CF Administrator that you can use to let CF manage whitespace suppression.

So I had a whitespace problem the other day and I was trying to get rid of it by all means necessary. I have all these options right? Something’s gonna work, right? Wrong! None of these things did it for me. I had a function in a component that you pass some arguments to and it outputs a