The latest Metro release (0.4) includes some bug fixes and a significant change to the included security package. After much consideration, I felt it was appropriate to separate the security package into "user" and "security" to facilitate integration with other projects and provide better separation of concerns. There is now a UserService which is responsible for managing the User, Role and Permission objects. The SecurityService is now primarily responsible for managing user sessions.
Additional meaningful updates below:
- The loginUser() method found in UserService, now checks the Active status for a User.
- The User decorator's hasPermission() method now accepts a comma separated list of permissions to check.
Logging is one of the classic cross-cutting concerns one hears about when discussing Aspect Oriented Programming (AOP). Other common aspects are caching, security and data transformation. Over the past year, I've begun to apply AOP with ColdSpring to my application design. I was completely confused about just what was going on with AOP, when I first looked at it, then, by degrees, I came to realize that it is actually pretty simple if you can focus on the basics without trying to absorb all the terms associated with AOP. With the release of ColdSpring 1.2, Brian Kotek wrote an excellent quickstart guide, that I recommend (especially for the AOP tutorial which I borrow heavily from for this example). I'll briefly describe how I wrapped my head around the concept.
I've started using Coldbox recently and really like the tooling it provides. I don't always have access to the ColdFusion logs for apps on shared servers and although I have worked with log4j, I didn't like property file configuration. The simplicity of the ColdBox logger is great, but I wanted to be able to set log levels and work with the standard debug(), info(), warn(), error() and fatal() methods. One way to achieve this is to mixin the desired behaviour. Another ColdBox plugin, methodInjector, allowed me to do just that.
I revisited the Metro ServiceFactory after John Whish's recent question about how Metro instantiates concrete classes. After a bit of trial and error, I'm happy to announce that the ServiceFactory now supports the creation of concrete gateways without requiring a concrete service in the same package. Before I outline how Metro resolves the class path for instantiating a Service and composed Gateways, I'll describe the basic conventions one must follow to use Metro.
The Transfer ORM Event Model provides an API for notifying components in your application of events in the Transfer object life cycle. You can use it to setup your component dependencies as demonstrated by Brian Kotek's TDOBeanInjectorObserver (part of his ColdSpring Utils library), or set specific properties on the Transfer object prior to creating or updating the object (see Bob Silverberg's post on the subject). Depending on your application needs, you can also tap into other Transfer events to create an audit trail and history for specific classes in your model. That's where the idea for the TransferAuditObserver (which is included in the Metro security package) was born. Setting CreateDate or LastModifiedDate properties on an object didn't sit well with me, because the observer was acting on the object state. Instead, I wanted an observer that recorded the events and state of of the object when those events were fired. Therefore, the TransferAuditObserver registers itself to listen for AfterCreate, AfterUpdate and BeforeDelete events, depending on a simple configuration map.
While in the process of generating documentation for Metro (using Mark Mandel's excellent Colddoc), I realized that I am generally remiss about using hint. Therefore, I embarked on a mission of adding hints to the Metro library. During the course of this exercise, I chose to re-factor a few items that I wasn't completely happy with. The result is Metro 0.3.1.
The latest version of Metro is now available on RIAForge. Here's the skinny on what has changed.
- Added an audit package
I've been using a Transfer AfterCreate and AfterUpdate observer to track changed to Transfer objects that I wish to track. Since this has become a common part of some of the apps I'm building, I decided to include it in Metro.
- Updated the core Service and Gateway to add getByProperty() support
I ran into a use case for this on a new project and decided to add it to simplify things.
- Fixed a bug in core Decorator related to validation rule creation
This update fixes a problem created when no min and max arguments are passed to addRule().
- Updated the security package to add "Active" attribute to User
Another use case addition. In order to provide a little more security to user registration, I added and Active flag to the User object.
In my brief introduction to Metro, I provided some cursory configuration details. Today, I'll describe portions of the included sample security package to demonstrate how to integrate Metro and leverage the simple User, Role, Permission model. Since Metro is designed specifically for use with Transfer ORM, we'll need to set up a database, dsn and configure Transfer and ColdSpring for this demo.
<cfset var obj = get(arguments.objectName,arguments.input[arguments.objectName&"Id"])>Is now this:
<cfset var pkName = getGateway(arguments.objectName).getPrimaryKey()>And the core Gateway has this new method.
<cfset var obj = get(arguments.objectName,arguments.input[pkName])>
<cffunction name="getPrimaryKey" access="public" output="false" returntype="string">These are small but important changes to the Metro library.