Oh, sorry, that was the title of the BACFUG presentation by Bill Shelton and Marc Esher (of MXUnit fame)!

Unit testing has defined my working day. I've been working on the licensing subsystem of the next build of the Broadchoice Workspace today and because we practice Test-Driven Development (thanx Brian!), that means writing unit tests "first" or at least alongside the production code.

I started by writing the License bean and an accompanying LicenseTest. The bean has a handful of properties and two methods. The unit test has nine test methods.

Fairly confident that the bean was correct, I moved on to the data layer. Apart from encryption, this mostly follows our well-tested generic Hibernate DAO. That meant only a couple of unit tests.

Once those tests passed, I moved on to the service layer. Six unit tests for four service methods.

At this point I'm ready to write the remote service facade (which implements user-level security) but I'm fairly confident our licensing subsystem will work as expected. 623 lines of code, just over half of which is unit tests (327 lines to 296 production code). I'll probably add some more data layer unit tests since I have a couple of "untested" methods (they're used in the service layer tests).

Unit tests may seem dull and tedious but they really can make your life easier.

Now that the Broadchoice Workspace has been officially released, I thought I'd post a quick entry with some code statistics. I ran the codebase through a line counting tool that gives a breakdown by file, folder, language, etc. We all know that lines of code is not a very good way to judge quality or effort, but it is still interesting in a general way. This is only lines of code, all blank lines and comments were excluded:

• Total Lines of Code: 50,125
• Total Files: 633
• Lines of MXML: 10,784
• Lines of ActionScript: 12,675
• Lines of CFML: 7,730
• Lines of Groovy: 8,878
• Lines of XML: 1,757
• Lines of CSS, HTML, JavaScript, etc.: 7,612
• Lines of SQL: 1,089
• Lines excluded as comments or blank: 15,778

Yesterday I blogged about how I set up Groovy/Spring to send both HTML and plain text emails. Today I want to share a tip about testing those emails. I was using postfix on my Mac as SMTP server. This allowed Spring to connect to, and send the email, but the emails would never leave my machine. My coworker Sean had no problem with mail getting out, so I figured I either had some setting wrong or perhaps it was my cable company blocking the traffic.

I googled around a bit and came across this excellent blog article: fully local testing of email sending web apps (on Mac OS X)

This article describes how to set up postfix to listen to certain domain names and forward those emails to local account. It then goes on to describe how you can setup a pop3 server to get those mails.

The end result is that you can send email to anything at a particular domain and then use a desktop client to check the mail. This is not only cool for Groovy work but would also be useful for ColdFusion as well. I normally use Spoolmail to check CFML generated mail, but that isn't an option for Railo, and it doesn't give a 'perfect' end user view of the mail (especially for combo plain text/html emails like we are testing).

Here at Broadchoice we've been working on our new product for close to three months now. I've gotten a crash course in Groovy, Spring, and Hibernate, all of which are slightly familiar to me from my time with ColdSpring, Transfer, and Java. I'm really digging these new technologies, but of course, I'm a die hard ColdFusion user at heart. A few weeks backs I needed to work on a quick iPhone web application prototype. Joe set up the connection and all I had to do was write CFML (lucky me). Little did I know that along with setting up basic CFML compatibility on the server, Joe also added one of the slickest things I've seen ever in my life as a developer.

The application I'm working on is pretty simple, but I wanted to use Model-Glue 3 for it since - well - you never know when a simple prototype will turn into a large, complex application. The following code snippet comes from a controller used to load bookmarks:

Nothing in the above code should be too odd or even that exciting really. I'm using a service (injected via the beans scope in Model-Glue 3) to retrieve my content. My controller begins with...

Note the beans value specifies which beans configured in ColdSpring should be passed to my controller. I love this new automation in Model-Glue 3. If you open up my ColdSpring.xml file, you will see my beans configured:

Hmmm. Ok, there's my config bean, wheres my contentService bean? Oh yeah - here it is:

You can find the above in our Spring file. Just in case the above didn't quite make get through, let me make it real nice and obvious:

The above line of CFML is using a bean injected from Spring, not ColdSpring, and points to a Groovy file. This is the same Groovy code used to drive the AIR application. No createObject("java") here baby. I'm using the Groovy code just like it had come from a CFC. This is done using a ColdSpring/Spring adapter that Joe wrote. It lets ModelGlue get Java-based beans from Spring. (I'm simplifying it here a bit, but hopefully you get the significance of that!) Once that connection is done, you can easily get beans from the Spring file and inject them into your controller. So for example, when my UserController wanted do handle login, I added: beans="userService,config" and then simply ran a userService.validateAndLoad on the authentication information.

It's always been easy to use Java from CFML, but never has been so sexy! Now to be fair, I did have to use a JavaCast once or twice, but not nearly as much as I would have thought.

If you happen to work with Adobe AIR at some point, and you want to download a file from a server, you may run into this helpful error:

I/O error 2038

Not very helpful. After a lot of digging and trying out solutions, I think I've figured it out. I was doing something like this in a Delegate object:

The problem seems to be the scope of the File object that is used to perform the download. Because it is locally scoped to that method, when the download completes and the completion event is announced, the file object is essentially gone. I'm not sure if AIR is garbage collecting it, or if the variable is just not accessible because it is function-scoped. Either way, I got this error over and over and was pulling my hair out.

The solution is to not var scope the new File object. Unfortunately that seems to open up potential concurrency issues. Because the Delegate object is essentially a Singlton, if I add the file as a public property of the Delegate, and more than one upload goes at the same time on the client, it will get overwritten. That's not good.

I got around it by creating an Object to wrap around my file called SharedFile. This object has a public property which is a File object. In that case, I can do something like this:

So I'm setting the sharedFile.file property to a new File, then using that file object to perform the upload. The I/O error vanishes because the file object is not locally-scoped, and so a reference to it still exists when the completion event fires. Again, I'm not sure of the exact underlying cause of the problem, whether a function-scoped file object is simply not visible when the completion event fires, or whether the AIR runtime is garbage collecting the variable before the completion event fires. Either way, this seems to fix it!

We're building out some prototype applications here at Broadchoice based on a Groovy + AIR stack that have multiple cases of data "push" to the AIR client.

At first, we took a traditional route of setting up destinations and Consumers for the different realtime cases, but that got pretty old pretty quickly, and we've put together a nifty system using server-side JMS and the Swiz framework. This'd also work with Cairngorm or any other MVC Flex framework that uses a central event dispatcher / front controller.

What's the architecture?

Swiz includes the idea of a CentralDispatcher that allows events to be dispatched outside of the UI component tree, allowing controllers (very Model-Glueish!) or even views to listen for application-level events.

On the server side, we've created a class (ApplicationEventMessage) that models a request for the client-side to create and dispatch (via Swiz) a DynamicEvent containing arbitrary properties.

By setting up a delegate that uses a Consumer (autowired by Swiz, of course!) the receives pushed ApplicationEventMessage instances to the client, we're using JMS on the server side to essentially dispatch events on the client side.

What's the result?

We've got a little controller on the client side subscribed to events of type "notification" that shows a nice little notification overlay in the application. When a user logs in, we want a notification of this login to get pushed to all other clients. Instead of setting up a new destination, a new consumer, and all of that rigamarole, we can just dispatch JMS message via the single consumer to send a message to client requesting that a DynamicEvent of type "notification" with a message property of "John Doe logged in" be created and dispatched.

Here's all the server-side code I had to write (in Groovy using Spring's JmsTemplate):

Taking it one step further, I wrapped this up in a simple service (wired into other services via Spring) that the rest of the team can use. For example, Brian Kotek was working on a small filesharing system and wanted to notify clients of new uploads.

Here's literally all he had to do to send out client-side notifications:

But Why JMS?

We're going to be targeting multiple platforms with some upcoming products. JMS is by no means Flex-specific, allowing us to use this same notification system to send realtime updates to clients other than Flex and AIR.

This morning, I published another tech doc for folks' use here at Broadchoice that was appropriate for sharing with the world. It describes how to configure a topic-style JMS destination within JBoss, connect a BlazeDS destination to it, and have a Flex consumer listen for messages from the BlazeDS destinatin (and therefore the JMS topic).

It's a Google doc, is available here:

Flex (BlazeDS), JMS, and JBoss in a Nutshell

I've been taking a look at the applicability of Chris Scott's Swiz Framework for use here at Broadchoice. So far, it's exactly what I'd expect - a fairly noninvasive way of wiring dependencies inside a Flex / AIR application that allows use of inversion-of-control.

One thing that threw me, though, was that Swiz approaches business delegates (wrappers for business services like RemoteObjects) from a total RPC standpoint. Instead of passing an IResponder to a new delegate instance each time you wish to use it like most Flex frameworks encourage, you simply write a delegate, instantiate it once in your BeanLoader, and use it as a singleton. Each of its methods that make server-side calls just return AsyncToken instances.

I really like this, as it makes the difference between a simple RemoteObject and a delegate wrapper completely irrelevant - your controller doesn't have a clue if it's talking to a delegate or not.

It did, however, throw me off from something I typically do. I normally write a "mock" delegate for any business service that "pretends" the server is there. Its useful in both unit tests and day to day coding: server may be down, backend code not written, etc.

In order to get this to work with Swiz, however, I had to simulate the presense of an AsyncToken and its related RPC events. Hence, I've cobbled together a MockAsyncToken and MockResultEvent that let you quickly set what you'd like a mock delegate to return:

...bam. Instant mock delegate. Thanks to Swiz, the rest of the app doesn't care that it's even there, and if I can use a plain RemoteObject, I never even have to write the "real" delegate.

Code for MockAsyncToken and MockResultEvent (dependency) is attached. Use at your own peril.

We have a live system with customer data and a new requirement comes along that a particular piece of customer data must be encrypted in the database from now on. We already encrypt some columns (using Triple DES - which you might have guessed given the recent posts on my blog and here about mimicking ColdFusion's encryption in Java/Groovy). What is the smallest possible code change to ensure that as any user updates their data in future, this item will automatically be encrypted - whilst still handling the case of legacy data being unencrypted?

We use Transfer for all our persistent business objects and almost all of our business objects have a decorator defined (for validation or some additional business logic). We also use Brian's TDOBeanInjectorObserver to automatically inject services into our business objects - just add a setter for a service and the bean injector takes care of the rest.

Here's the bean injector definition in our ColdSpring file:

Normally you would declare it non-lazy but we already do other non-lazy initialization so in our ColdSpring factory initialization code, we do this: to force the bean injector to be initialized which, in turn, registers itself as a Transfer event listener (so that it can intercept object creation). The suffixList specifies that any set*Service() method or set*Datasource() method on the business objects managed by Transfer should be matched to beans defined in ColdSpring and injected.

So how do we add the on-demand encryption to our business object's data?

[More]

So the title is a bit of a trick. This really isn't about writing your second Model-Glue application, but more about the kinds of things you see when comparing earlier Model-Glue applications to those you write after having a few under your belt. Most likely a lot of what I'm going to talk about applies to other frameworks as well, so this isn't just a Model-Glue concern. When I arrived at Broadchoice, the older version of our product had already been updated to use the Model-Glue framework. The primary developer team behind this update had just learned Model-Glue. A lot of what I saw looked very similar to how I had built Model-Glue sites when I began. Here are a few items to consider when building your next Model-Glue application.

Model-View-Controller need not be singular...
For those of us who were new to MVC, the idea of nicely separating back end logic from front end views was a godsend. Sure it meant a bit more work up front, but the benefits later on were more than worth the effort. I think this is the thing I appreciated the most about MVC. So, like most people, I began to work with a controller, a ModelGlue.xml file, and maybe a few model files and my directory of views. This worked fine for a smaller site, but as the site began to grow, my XML configuration and controller file began to explode. When I needed to find an event, I was scrolling through 1000 lines of XML. Even if I used a nice naming scheme (more on that below), it was a chore to work with. When I began using Model-Glue, there wasn't a simple solution for this. Luckily the framework added support for XML includes.

I ran into the same issue with my controller as well. The file had become too large to manage. It didn't even occur to me to use multiple controllers until I had done a few Model-Glue sites, but now that I have I wouldn't do it any other way. My typical approach is to break up the controllers by "areas of concern" - which is my way of referring to the major parts of the application. So for example, a typical site may have a User, Product, and News controller. Each would be responsible for handling events related to their areas. So the User controller would handle listening to getUser. Product would listen to getProduct. Etc.

I still keep a controller named, well, Controller, because I find that there are typically events that don't fall into any one particular category. I also still put a few events in the main ModelGlue.xml file.

What's nice about MVC, and where I think it really "sinks in" for developers new to the concept, is that you can update a Model-Glue site to fix this problem and not lose a drop of functionality. So at Broadchoice, I've been slowing breaking things up a bit when there are available cycles. This has zero impact on the product for the end user but has the side effect of making it easier to update the application.

I also recommend breaking up the views folder. It may start small, but before you know it any semi-complex site can grow quite complex. The main idea here is to make it as simple as possible for someone to find the right code when performing updates.

Inconsistent Naming
Ok, so this may be more of an issue for those of us who are anal retentive about naming, but I really get bothered when my event names don't follow a standard naming pattern. Inconsistent naming is an even bigger problem if the files aren't properly broken up (see above). There are no hard and fast rules for what makes a good event name. My typical rule is "area of concern"."action", so I will typically have events like:

• product.edit
• user.authenticate
• planet.destroy

This way it's always clear what type of data (or area of the application) is being worked with, and what type of action is being performed. Once again, the beauty of MVC is that you can make these types of corrections when you have time for it. There are two potential problems with this.

First - you may have existing URLs that rely on certain event names. In the past I've handled this by either using a URL rewrite or by catching the "missing event" error in Model-Glue. Model-Glue 3 adds support for handling missing events directly so this will get even cleaner. While you should put some thought into how you name your events, it may make sense to pay extra attention to those events the users will actually see (and possibly bookmark).

The second problem is a bit harder to fix. If you change the event that is run when a user logs in, it isn't just enough to update the XML. You also have to remember to update the view layer as well. I was never really a big fan of the XFA technique. This is a Fusebox concept whereby you tell the view what to use for particular events. (I believe this originated with Fusebox - if anyone knows better, speak up!) So instead of me hard coding action="index.cfm?event=user.authenticate" in the form tag, I'd pass it to the view layer and make the action dynamic. After doing some refactoring on our product, which made heavy use of XFAs in Model-Glue, I'm really happy they were used. Here is a simple example from one of our views:

Note the use of the value subkey inside the view node. This will add the values to the viewState. You would then use these when creating any links within the view.

Anything else?
This is - in general - the big things I've noticed when looking at first generation Model-Glue sites. I'm curious to see what others have discovered as well, so please chime in with your comments.

I'll add one more thing to the list - I wish like heck I had made more use of auto-wiring and ColdSpring in general. Until you see a good example of an application that uses this you don't truly get how much work it can save you.