Once you get an appreciation for the importance of unit testing and integration testing is when we reach a new level in our development careers.  Testing is critical to mission critical applications, and even for our own little projects, where we test that our code should work as expected.  There’s that word again, expected.  Expectations in unit testing is like a nasty hamburger at a soccer match in El Salvador.  They go hand in hand :)

Read more...

Thanks to our 3.0.0 milestones, the SES capabilities have been really fine tuned and added some great concepts in order to enable it for more RESTful applications.  We have added things like:

• -alpha : Alpha only placeholders
• {X} : Digit quantifiers for all placeholders
• constraints : A separate structure where you can give any placeholder your own regular expression
• RESTful actions : A way to split actions according to the incoming HTTP method

The last one is what we will concentrate on.  In true RESTful style URLs, we must concentrate on the concept of resources or endpoints we are trying to describe.  Say: http://www.example.com/users  most likely will represent users, but we could also have: http://www.example.com/users/lmajano which describes a user but with a more detailed part which is lmajano.

Requests and responses are built around the transfer of "representations" of "resources"

"Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use."

It is also important to note that REST is a style of URL architecture not a mandate, so it is an open avenue of sorts.  However, you must stay true to its concepts of resources and usage of the HTTP verbs.  Here are a few pointers when using the HTTP verbs:

• POST : Create a resource
• GET : Retrieve a resource(s)
• PUT : Update a resource
• DELETE : delete a resource

So examples for true RESTful URLs:

• GET /users
  return a list of users
• GET /users/lmajano
  return the representation of user lmajano
• POST /users
  create a new user with post data
• PUT /users/lmajano
  Update the lmajano user
• DELETE /users/lmajano
  Delete the lmajano user

So how can we do this in ColdBox? Very easily! The new 3.0.0 SES interceptor allows for a pattern to be bounded to a handler and a structure of actions that match the incoming HTTP verbs:

// User representation

addRoute(pattern="users/:user",    
handler="rest.Users",    
action={    
GET = "show",    
POST = "create",    
DELETE = "remove",    
HEAD = "info"    
});

 

As you can see, the action argument can be a structure or a JSON structure of mappings between HTTP verbs and the action method you wish to fire whenever the resource is accessed with that method.  So if I go to /users/lmajano with a DELETE, then we will execute: rest.Users.remove().  So the approach of binding HTTP verbs to the correct actions, can give us TRUE RESTful URLs instead of us trying to create tons of URL representations and always using POST and GET. 

In conclusion, ColdBox 3.0.0 adheres to the standard RESTful principles and gives you a way to do HTTP verb to action mappings very easily when creating your resource URLs.  Stay tuned for more information on other useful RESTful features we have on 3.0 like:

• HTTP method security right from within your handlers
• onError() conventions when RESTful handlers throw exceptions
• Request context updates to retrieve headers and content
• Much more

With ColdBox 3.0.0 you can use any kind of regular expression with your SES routes which makes it extremely flexible.  One way to accomplish this is by using the constraints arguments when calling the addRoute() method to add a routing entry. So if I wanted to add a placeholder that matches a regex then I would do this:

addPattern(pattern="/api/:format/", constraints={format="(xml|json)"})

As you can see from the code above, the constraints argument is a structure in which the keys match a :placeholder in the pattern string.  Then you start of the values with a parenthesis so the expression can be grouped and match and then I place my regex, which in my case is a simple xml or json value.  However, you can get very funky and use your own regular expressions on ANY placeholder.

This is a quick guide to showcase a cool new feature in ColdBox 3.0.0 that helps you create routes based upon your own regular expressions and needs.  Before (coldbox < 3.0.0) you created routes with placeholders and these placeholders could be alphanumerical or numerical values.  In ColdBox 3.0.0 they can be alphanumerical, alpha, numerical, and custom.  Custom is what we are after, which makes URL Mappings in ColdBox 3.0.0 extermely flexible.  So let me pinpoint the use case. I have two URLs that need to be aliased to the same handler+action combination and I want to be creative and have one cool route for them instead of two. URL1: /en/chat URL2: /en/assist So I can use the following route to basically be able to match both URLs in one single route using our fabulous new constraints. //Using cf9/railo implicit structs ROCK!
addRoute(pattern="/en/:chat",
    handler="support",
    action="chat"
    constraints={
    chat = "(chat|assist)"
    });

// Using JSON notation for CF engines < 9addRoute(pattern="/en/:chat",
    handler="support",
action="chat"
    constraints="{
    'chat' : '(chat|assist)'
    }"); As you can see there is a new argument in the addRoute method called constraints, which basically is a structure or JSON structure of custom regex constraints on placeholders. This way, you can easily match whatever you like to incoming URLs. In my case my regex was a simple list of two static parts. Yours could be more fancy! Anyways, hope you enjoy this new feature.

Self admittedly, I am new to Unit Testing. It is on my list of things to learn and implement into my development toolbox and workflow for 2010. So, officially, I have begun the process using the Base Test Case ColdBox has built in and the illustrious MXUnit of course.

All my testing was working great until I wanted to test something that was using CF9 ORM/Hibernate integration.

The first issue I had was that ColdBox creates a separate application for testings. That is, the test folder has its own application.cfc defined. Well, obviously by default, that application.cfc doesn't have ORM setup, which then of course caused me not to be able to test anything that relied on or used an ORM "persistent=true" cfc or did an EntityLoad or anything like that.

So, the workaround for this issue is pretty simple.

First, open up the application.cfc in the test folder, then setup a mapping to your base application your testings. Call it whatever you like, I called my mapping baseApp.

this.mappings["/baseApp"] = expandpath('../../');

You can change the pathing to match your given scenario.

Then you need to configure orm in the application.cfc.

this.ormenabled = "true"; this.datasource = "MyDSN"; this.ormsettings = {cfclocation=["/baseApp/model/ORM","/baseApp/modules"]};

And there you have it, ORM is now configured for your testing application and you can test away.

Read more...