ArgumentCollection - Broadchoice Engineering - Broadchoice Shares Knowledge

Transfer ORM and memory usage

Sat, 14 Mar 2009 19:05:00 -0400

Some people - myself included - have observed runaway memory usage and apparent memory leaks with applications built with certain combinations of CFML frameworks that include Transfer ORM. We spent a lot of time tuning the JVM and looking at code and database usage in our Broadchoice Community Platform (CMS), we worked with Mike Brunt on load testing and tuning (highly recommended - if you have any performance problems, get Mike on your case!) as well as working with Mark Mandel directly on Transfer itself. All that work led to a much more stable system and we decided to just continue investigating as a background task. [More]

Broadchoice Community Platform 2.0.11 Released

Wed, 11 Mar 2009 19:04:00 -0400

As I Twittered on Monday, the new release of the Broadchoice Community Platform (our hosted content management system) was in QA and had hit zero bugs. QA completed successfully so today we pushed the new release to production. It's mostly a bug fix and minor enhancements release but it contains one new feature I wanted to talk about from a technical point of view. The Community Platform has a number of "modules" (applications) that you can add to a page and one of those is a list of documents for download (or external links). You add the module to the page and then select documents (from your document library) to add to that module. In previous releases, authors had to add documents in the order that they wanted them to appear on the (generated) web page. We looked at a number of UI options for allowing authors to "rank" the documents within the module but felt most of them were fairly clunky, involving entering ranking numbers to reorder things or up/down arrows requiring authors to move documents one position at a time. Ugh! Ray pointed me at one of the cool jQuery UI interactions: sortable. It allows you to mark a "container" tag (e.g., a div) as sortable and then users can drag'n'drop the "child" elements into the order they want. You can attach event handlers that fire at various points in the drag'n'drop operation. Here's how we do it:



  
    
      #documents.name# ... etc ...

That's all you need in the HTML. Then you add the following JavaScript:


$('#sortable').sortable({
  update: function(event,ui) {
    jQuery.get('/updateRank.cfm?' + $('#sortable').sortable('serialize'));
}

This causes two things to happen:

jQuery marks the sortable div contents as being, well, sortable!
jQuery adds an event handler for update - when the drag'n'drop operation completes - that invokes a URL on the server, passing in the serialized data from the children of the sortable div, i.e., the id values as a list in the new order: doctag[]=1,3,4,2. It assumes an underscore as a separator.

The server side code simply updates the module data to put the documents in the specified order.

Custom Getters and Flex Remoting "gotcha"

Fri, 27 Feb 2009 20:15:00 -0400

I ran into an interesting bug in the final stages of preparing the latest release of the Broadchoice Workspace application. I had added a custom getter to an ActionScript object to calculate a complex property, along these lines:


public function get complexProperty() : SomeType
{
	performSomeCalculation()
	return someComplicatedExpression
}

This allows you to say myObj.complexProperty without needing parentheses for a function call (and with a matching custom setter, you can assign to the pseudo-property as well). It's a nice feature of ActionScript that can really make your code much more readable. The particular getter I added was only valid when certain data in the object was non-null. In all of the mainline use cases inside the application, this was fine. The complexProperty was only ever accessed after testing the condition on the object:


if ( myObject.someCondition )
{
	doStuffWith( myObject.complexProperty )
}

Yes, someCondition was a custom getter as well. The bug I ran into was that sometimes remote calls involving this object silently failed. I didn't get a fault back. It was almost like the call just didn't happen. Puzzled, I fired up the Flex Debugger (which is absolutely awesome!) and traced through the code. No visible exceptions, no strange paths being executed in the code. More puzzled, I fired up JBoss in the Java Debugger under Eclipse and put a breakpoint inside the server method that was called. Strangely, the code ran without hitting the breakpoint! That showed that the call really was not happening for some reason. Back in the Flex Debugger, I set a breakpoint just before the remote call and took a very close look at the object in the Variables panel when I hit the breakpoint. It showed the custom getter as a property on the object (as expected) but the value in the debugger showed an exception was thrown retrieving the property. Then it hit me: Flex Remoting tries to serialize the object by calling the getters and it was failing due to the exception - and silently swallowing the exception without telling me, and without executing the remote call! I updated the getter to return a default value if the condition (myObject.someCondition) was false and, sure enough, the object serialized just fine and the remote call was successfully executed! Moral of the story: if you add custom getters to ActionScript objects, make sure they cannot throw an exception when the object is in a state where you need to send it to the server using Flex Remoting!

ColdFusion in the Cloud Revisited

Fri, 09 Jan 2009 16:23:00 -0400

About a month ago, I talked about my experience of setting up clustered ColdFusion instances on EC2. Since then we have migrated the Broadchoice Web Platform completely from a regular data center, where it had lived since launch, to the Amazon cloud and now all of the *.broadchoice.com sites and all of our client sites based on the Web Platform are happily running in the cloud. We've been very pleased with the performance and stability of EC2 so far and we're comfortable about scaling out as demand increases. We took advantage of Amazon's EBS (Elastic Block Storage) that allows you to mount S3 storage directly as part of the file system on EC2. This essentially replaces the NAS we were using in the data center where all uploaded files were placed. We run two ColdFusion instances on a medium EC2 instance and run MySQL on a separate EC2 instance (actually on the instance that is currently running our AIR application, the Broadchoice Workspace for Salesforce, along with its MySQL database). We replicate the MySQL databases to another server (in a data center) so that we can restore / recover in the event of a problem with EC2. We also run scheduled backups of the EC2 instances to S3. As I noted in my earlier entry, we're using Apache and the JRun Connector to manage the two instance cluster and failover. I'm still suspicious of the connector due to past experience but so far it has been behaving well and when we restart instances for maintenance, we're generally seeing uninterrupted service, from a user's point of view, as requests silently failover to the other instance. If you're interested in running ColdFusion in the cloud, you'll need to talk to Adobe about licensing (either Adam Lehman or Kristen Schofield) but they are being very encouraging because they want this to happen. The more of us who do this, the better the argument they can present internally to get the EULA changed to support ColdFusion running in the cloud! If you want to learn more about how we handled the migration and/or what to watch out for when designing applications that run well on the cloud, feel free to contact me via this blog or directly (c'mon, you know my email address!).

Recentering Flex Alerts on Application Resize

Mon, 05 Jan 2009 11:51:00 -0400

I recently had a bit of a challenge to tackle with our Workspace application and thought I would share some details. As many of you probably know from trying out the application, Workspace is meant to be kept open to fully capitalize on it's collaborative features. The application provides a lot of behavior that is based on real-time communication, such as content being updated or users being added to Spaces. All of this works quite well right now, and we are already working on more features as well as some simplification of the interface to allow new users to get up and running more quickly. We have, however, noticed a small but annoying glitch that happens as a result of certain real-time notifications that trigger Flex Alerts. Namely, if the application is minimized and an Alert is triggered, when the application is maximized, the Alert does not appear in the proper place. Normally, an Alert will automatically center itself in the window where it appears. But if the application is minimized, this centering does not happen. So when the app is maximized again, the modal Alert is located far in the upper left corner of the screen, with most of it's content off the screen completely. Users had a hard time figuring out what was happening, and since the Alert is modal, the app can't be used until the Alert is closed. This resulted in a lot of confused users! I set out to solve this issue by triggering a re-centering of any open Alerts when the application is resized, but this turned out to be more difficult than it first appears. At first, this seemed like it should be fairly simple: the Flex SystemManager object contains a property called popUpChildren, which references any PopUp objects that are open. So no problem, right? Just loop over this list and recenter them. In a frustrating turn of events, Flex Alert objects are not stored in this list. I'm not sure why, but they aren't. This seems like an oversight or bug, but the fact remains that looking at the popUpChildren wouldn't work. This list appears to only contain any PopUp instances created using the PopUpManager, but not any Alert instances. Nor is there a similar list such as alertChildren. It turns out that Alerts are added to the SystemManager's display list but are not actually kept track of anywhere. The first part of the solution was to add an application resize event handler that loops through all children of the SystemManager's display list and locates any that are instances of the Alert class:


var systemManager : SystemManager = Application.application.systemManager;

// Look for children of SystemManager that are Alerts, and recenter them.
for ( var i:int = 0; i < systemManager.numChildren; i++ )
{
	var thisChild : Object = systemManager.getChildAt( i );
	if( thisChild is Alert )
	{
		PopUpManager.centerPopUp( thisChild as IFlexDisplayObject );
	}
}

This code actually does work and will recenter the Alert. But in another frustrating turn (and what certainly appears to be another bug), the re-centered Alerts did not display correctly. Any text within the Alert box that was "off the screen" prior to re-centering would not display. I tried triggering an invalidateDisplayList() and invalidateProperties(), but nothing would get the Alert to re-draw the text correctly. I was banging my head against the monitor when my astute colleague Joe Rinehart made a suggestion that turned out to give the desired result:


var systemManager : SystemManager = Application.application.systemManager;

// Look for children of SystemManager that are Alerts, and recenter them.
for ( var i:int = 0; i < systemManager.numChildren; i++ )
{
	var thisChild : Object = systemManager.getChildAt( i );
	if( thisChild is Alert )
	{
		PopUpManager.removePopUp( thisChild as IFlexDisplayObject );
		PopUpManager.addPopUp( thisChild as IFlexDisplayObject, this );
		PopUpManager.centerPopUp( thisChild as IFlexDisplayObject );
	}
}

Essentially, you have to kick Flex in the head by removing the Alert, re-adding it, and then re-centering it for good measure. All of this seems like a lot of hoops to jump through to accomplish something that seems like it should be rather easy to do, but there you have it. Going forward, we'll probably set up some sort of centralized manager class that can be used to create and keep track of both Alerts, PopUps, and any other components that need to display at the very top display list of the application (such as Callouts and Tooltips), and we're also looking at some Growl-like notifications to minimize the use of Alerts. But that's a topic for another day (probably in the very near future though). In any event, hopefully this post will help anyone who ends up in a similar situation!

Unit Testing Improves Your Love Life

Wed, 26 Nov 2008 04:06:00 -0400

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.

Some Code Statistics for Broadchoice Workspace

Fri, 14 Nov 2008 20:10:00 -0400

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

Email Testing on OSX

Tue, 11 Nov 2008 13:05:00 -0400

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

Is it ColdFusion or Groovy?

Mon, 03 Nov 2008 17:52:00 -0400

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:



    
        
            /some url you dont need to know
            /something else you dont need to worry about
            10

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.

AIR File Download Gotcha

Fri, 29 Aug 2008 13:42:00 -0400

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:


public function downloadFile( fileName:String ):void {
	var req:URLRequest = new URLRequest( this.sharedFileDownloadURL + fileName );
	var file = new File();
	file.addEventListener( Event.COMPLETE, saveCompleteHandler );
	file.addEventListener( IOErrorEvent.IO_ERROR, ioErrorHandler );
	file.download( req, fileName );
}

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:


public function downloadFile( sharedFile:SharedFile ):void {
	var req:URLRequest = new URLRequest( this.sharedFileDownloadURL + sharedFile.name );
	sharedFile.file = new File();
	sharedFile.file.addEventListener( Event.COMPLETE, saveCompleteHandler );
	sharedFile.file.addEventListener( IOErrorEvent.IO_ERROR, ioErrorHandler );
	sharedFile.file.download( req, sharedFile.name );
}

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!

JMS + Swiz = Evil Realtime Flex.

Fri, 22 Aug 2008 12:13:00 -0400

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



def message = new ApplicationEventMessage(
	eventType: "notification",
	data: [
		message: "John Doe logged in"
	]
)
	
jmsTemplate.send(
	[
	 	createMessage: { Object[] params ->
	 		def session = params[0]
	 		return session.createObjectMessage(message)
	 	}
	] as MessageCreator
)

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:


def message = new ApplicationEventMessage(
		type:"fileUploaded",
		data: [
			message: fileItem.name + " was added to the shared files."			
		]
)

messageDispatcher.dispatch(message)

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.

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

Wed, 20 Aug 2008 13:27:00 -0400

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

Swiz and MockAsyncToken

Mon, 18 Aug 2008 13:18:00 -0400

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:



// Mock'd RPC function
public function getUser() : AsyncToken
{
 // just pass the desired server response to the MockAsyncToken's constructor
 return new MockAsyncToken(new User());
}

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

Better Living Through Transfer and ColdSpring

Fri, 15 Aug 2008 22:45:00 -0400

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:



	
	service,datasource
	true

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]

Writing your Second Model-Glue Application

Thu, 14 Aug 2008 18:45:00 -0400

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.