ColdFusion in an Enterprise Environment - Part 2 - Choosing ColdBox

There is many reasons I have picked coldbox over other CF frameworks, but I don't want this to get into why, should I, or you idiot you shouldn't of picked coldbox because -x- framework is better. Rather, I'd rather explain how I are using the framework to make development easier with an office of developers. The following are seven of the reasons I choose coldbox

1.) ColdBox.org provides a lot of great documentation, and almost overstates the amount of documentation. It does have a lot of great documentation, especially some of its competitors. But some of the documentation is not layed out well for someone jumping into a framework. But this is one of the reasons I choose coldbox.

2.) Provides MVC!!!! And it provides it by forcing you to code. Providing you the most powerful MVC capabilities, not wrapped into AOP, forcing a developer to design it out before he just starts coding and expecting the framework to do it for him/her. Sorry this was a little strong opinionated, I see the need for AOP framework, but not for every application. Which leads to another reason I choose coldbox over the others.

3.) Coldbox plays well with other frameworks. Providing you the ability to do less SQL coding using transfer (assuming it is a good business decision), providing you the ability to do injection processing when needed using many different frameworks.

4.) Convention… nice and clean… I let you read about it here http://ortus.svnrepository.com/coldbox/trac.cgi/wiki/cbDirectoryStructure

5.) Integration into UNIT testing frameworks like MXUNIT.

6.) Integration into my favorite IDE… eclipse.

7.) Other advanced features I have yet to get into yet. Like plugins and interceptors..

Please Note: This post is conjuction with a series of blog posts about my findings in setting up an enterprise development environment. Please view the rest of the posts at Coldfusion in an Enterprise Overview

ColdFusion in an Enterprise Environment - Part 1 - Understanding how to use SubVersion (SVN)

Subversion can be used in many ways, so this isn't the holy grail of how you need to use subversion, but it does add application management to subversion. What does application management mean? Well, the definition for this article is how to control what gets released into production.

This article is not going to go into how to setup version, or how to add an external to the repository tree. But how in concept to use SVN and an external to achieve application management.

First of course you need a SVN repository, which for the purpose of this article our repository will be noted as "/".

Second we need to know that will we still be using the concepts of trunk, tags, and branches, they just won't live in the root of the repository. The trunk is the current working copy of development, while the tag folder is to version releases (by tagging). Branches will be used when "new" development is going on and emergency coding is required on the existing code base before the new development will be completed.

Lastly, we need to understand what will be in the root of the repository. These folders are instances, projects, and vendors. Therefore, the SVN repository will look like

/
instances/
projects/
vendors/

Vendors is any code not developed by our developers. For example, jQuery would be in the vendor location, therefore giving us the ability to manage what version of jQuery is in each environment. Each folder under Vendor, for example jQuery, should have a trunk, tag, and branch folders.

Projects is each sub-application in our product and it is each supporting product. For example our enterprise has a central account management API, which is only accessible through web services, therefore, a wrapper for that API will be project. While the product that uses the wrapper to the api is also another project folder.

Another example describing the separate project methodology is a shopping cart application, you'll have the cart, sales tax calculator, shipping calculator, billing information, and the shopping cart application itself. The proposed use of this would have each of those in separate folders so different developers can work on different areas in a unit testing methodology.

With separating everything the need for one "project" for the actual application still exists. Right now this requires the developer to know the relationships when extracting projects out of SVN. If a developer is required to work on the actual application, the developer would need to extract all other projects, for example, editing the login/authentication UI would require the wrapper to the authentication API, therefore, needing to pull 2 projects out of SVN.

Lastly, each folder within the projects will have the normal folder structure of trunk, tags, branches with the code under each specific one where necessary.

Instances is each environment in existence. For our setup we have a development, Quality Assurance, and Production. This folder "control" your deployment of your code, or in different phrases, this folder contains the code to be copied to each environment. The use of externals will give us the ability to not replicate the code within the repository. The uses of tags (or tagged versions) will give the ability to control what version exists in each environment.


Lastly, I will be touching on how we use this layout further as I get into how to use ColdBox and MXUnit while developing.

Please Note: This post is conjuction with a series of blog posts about my findings in setting up an enterprise development environment. Please view the rest of the posts at Coldfusion in an Enterprise Overview

mxunit and validation exceptions

WIthin my models I use "doValidate" functions that throw an exception of "validationExceptions", which you can read about here,  I am now getting into unit testing with MXUnit!!  So, I wanted to unit test my validation exceptions, therefore, i needed away to capture the exception and compare the number of validation errors returned to how many i expected.

The following is one of my mxunit test functions that trap the validationException error:

<cffunction name="testValidateForPassword2" displayname="password and verified password do not match" access="public" returntype="void">
    <cfscript>
        oFpsGTW = createObject("component","fps.model.FpsGTW").init(fpsServerURL="#variables.instance.fpsURL#");
       
        oFpsDTO = setupGoodDTO();
       
        //SET check not equal passwords
        oFpsDTO.setPassword("abcabc12");
        oFpsDTO.setVerifiedPassword("ababc12");
           
        actual = 0;
        expected = 1;
        try {
            oFpsGTW.validateForPassword(oFpsDTO);
            actual = 0;
        } catch (edu.psu.uao.exceptions.ValidationException e) {
            actual = e.length();
        }

       
        assertEquals(expected,actual,"Validation Routine Error");
    </cfscript>

</cffunction>

ColdFusion in an Enterprise Environment - Overview

Over the past 12 plus years, I have been Coldfusion programming. Early on I coded within Coldfusion very inefficiently, because of both Coldfusion being young, and because I was young. And since 2001 I have coded in a "object" methodology within Coldfusion . I started with CFObjects (url used to be cfobjects.com). And until late last year I really haven't expanded my object oriented capabilities.

Over the past year, I had the opportunity to take a java class with a great instructor and I also had the opportunity to review all the Coldfusion frameworks. With learning the MVC concept and design patters I am now ready to take the endeavor of using MVC and design patterns in an enterprise.

Good or bad I have chosen Coldbox to help implement MVC concept in our enterprise applications. The reason I'm blogging about it, I haven't seen to many explanations on how a group might use it for an enterprise application, or set of applications that work together.

You might say, well lots of us use Coldbox in an enterprise. Let me clarify what I mean: The applications myself and our development staff create {customer mgmt, events, campaigns, Application for Admissions, and all the supporting code that goes with interacting with a enterprise application} all interact with each other, basically we are building a customer management system (CMS). Where a CMS has many sub-applications that collaborates with each other.

So over the next couple of weeks I plan on laying out how to use Coldbox and subversion to control our application management process. This includes but not limited to how we organize our code within subversion, organize our code during deployment, how we unit test, how Coldbox fits into the picture.

As I write each part, I will update this blog to contain a link to the other parts.

• Overview (this blog article)
• Part 1 - Understanding how we plan to use SubVersion (SVN)
• Part 2 - Choosing ColdBox
• Part 3 - Choosing Unit Testing Framework
• Part 4 - Putting SVN/ColdBox/Unit testing together
• Part 5 - Creating a Local development environment.
•