Fancy Bread

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.

Read more...

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.

Read more...

In the first part of Using Metro, I reviewed the Service and Gateway portion of the Metro security package. In this post, I'll describe the core Metro Decorator and Validator as well as the jQuery plugin I use for client side validation.

Read more...

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.

Read more...

The latest release (0.2) of Metro eliminates a convention on naming object Ids (or your database table Primary Key). Like a lot of developers, I tend to name my table PK as table name plus "Id" - UserId, AddressId, etc. I used this convention within the core Service for Metro, but I was unsatisfied with that limitation. Using Metro should not force one to adopt another developers convention(s). So I re-factored the core Service and Gateway to use Transfer metadata instead. Object retrieval in the Service save() method which looked like this: <cfset var obj = get(arguments.objectName,arguments.input[arguments.objectName&"Id"])> Is now this: <cfset var pkName = getGateway(arguments.objectName).getPrimaryKey()>
<cfset var obj = get(arguments.objectName,arguments.input[pkName])> And the core Gateway has this new method. <cffunction name="getPrimaryKey" access="public" output="false" returntype="string">
<cfreturn getTransfer().getTransferMetadata(getClassName()).getPrimaryKey().getName()>
</cffunction> These are small but important changes to the Metro library.