Fancy Bread

Over the past year, I have dabbled more and more with leveraging AOP in my applications,primarily for logging and caching. Recently, I needed to analyze a system for performance and determined that for some operations, there were several points where third party integrations are managed. These points slowed the request lifecyle dramatically and were targeted to be re-written using cfthread. I love a good refactoring challenge as much as the next guy, but I also love a good abstraction. Thus, the AsynchronousAroundAdvice was born.

Read more...

Metro is creeping ever closer to a 1.0 release, which will likely be followed up by something else in short order.  I never really set out a timeline to development, instead, I've let the needs of my current project drive the schedule.  Today marks the 0.9 release which features one improvement (depending on how you look at it) to the TransferAuditObserver. The first cut of the Observer focused on recording create, update and delete events and the class and PK of the object which fired the event.

I needed the ability to invoke a custom method on the observer, so I re-factored the Observer to accept a tad mo' metadata. Here is the new ColdSpring configuration and a sample Observer which extends metro.model.security.TransferAuditObserver. The configuration now allows one to specify a target method by class.

<bean id="AuditMap" class="coldspring.beans.factory.config.MapFactoryBean">
    <property name="sourceMap">
    <map>
    <entry key="create">
       <map>
          <entry key="some.Class">
          <value>doSomething</value>
          </entry>
          </map>
    </entry>
    </map>
    </property>
   </bean>

   <bean id="MyObserver" class="model.package.MyObserver" lazy-init="false">
      <constructor-arg name="transfer">
         <ref bean="transfer" />
      </constructor-arg>
      <constructor-arg name="auditMap">
         <ref bean="auditMap" />
      </constructor-arg>
      <property name="SomeService">
         <ref bean="SomeService" />
      </property>
   </bean>

And here is a sample Observer.

<cfcomponent displayname="MyObserver" output="false" extends="metro.model.security.TransferAuditObserver" hint="I am a Transfer AfterCreate, AfterUpdate and BeforeDelete observer.">

   <cffunction name="doSomething" hint="Performs some important event driven action" returntype="void" output="false" access="private">
      <cfargument name="obj" type="transfer.com.TransferObject" required="true" hint="The event object">
      <cfargument name="action" type="string" required="true" hint="The action that occurred (create|update|delete).">
      
      <cfscript>
       // something gets done.
      </cfscript>
   </cffunction>

</cfcomponent>

The latest release for Metro (0.8.2) is now available. This release sees the addition of another service method and some significant updates to the service api.

create
The new create returns a populated and validated Transfer object. If the object passes validation, it is persisted. The default validation context is "all". Here is the method.

<cffunction name="create" access="public" output="false" returntype="any" hint="I return a populated and validated Transfer object.">
<cfargument name="objectName" type="string" required="true" hint="The Transfer object name.">
<cfargument name="input" type="struct" required="true" hint="The input struct of key/value pairs.">
<cfargument name="context" type="string" required="false" hint="The validation context." default="all">
<cfset var obj = new(objectName: arguments.objectName)>
<cfset obj.populate(args: arguments.input)>
<cfif obj.validate(context: arguments.context)>
<cfset getGateway(arguments.objectName).save(obj)>
</cfif>
<cfreturn obj>
</cffunction>

save
The save method now also returns a populated and validated Transfer object. If the object passes validation, it is persisted. The default validation context for save() is "all". The difference between create and save is that the former populates and validates a new object, whereas the latter "gets" the object using the input struct as the key (get will intelligently build the correct key from the input struct) and uses clone(). Here is the method.

<cffunction name="save" access="public" output="false" returntype="any" hint="I return a populated and validated Transfer object.">
<cfargument name="objectName" type="string" required="true" hint="The Transfer object name.">
<cfargument name="input" type="struct" required="true" hint="The input struct of key/value pairs.">
<cfargument name="context" type="string" required="false" hint="The validation context." default="all">
<cfset var obj = get(objectName: arguments.objectName, key: arguments.input).clone()>
<cfset obj.populate(args: arguments.input)>
<cfif obj.validate(context: arguments.context)>
<cfset getGateway(arguments.objectName).save(obj)>
</cfif>
<cfreturn obj>
</cffunction>

You can probably guess that I use create when trying to persist a new object and save for an update. Let's look at a sample coldbox controller that uses create or save.

<cffunction name="doSave" access="public" returntype="void" output="false">
<cfargument name="Event" type="any">

<cfscript>
var obj = "";
var context = "";
var message = "";
if (event.getValue("UserId",0) == 0) {
// create
context = "new";
message = "User successfully Added.";
obj = getUserService().create(objectName: "User", input: event.getCollection());
} else {
// save
context = "edit";
message = "User successfully Edited.";
obj = getUserService().save(objectName: "User", input: event.getCollection());
}
if (!obj.hasErrors()) {
setMessage(type: "success", message: message);
setNextEvent("user.list");
} else {
event.setValue("User",obj);
setNextEvent(event: "user." & context, persist: "User");
}
</cfscript>
</cffunction>

In the past, the save() method returned a result with a success flag, an array of errors and the obj as a payload that you could access via getResult(). I have since moved to maintaining the errors within the Transfer object, which renders a result object useless. Thus the change to the save() method.

list
The list method now accepts the "orderBy" and "asc" arguments to provide better control of simple list operations. Here is the list() mthod.

<cffunction name="list" access="public" output="false" returntype="query" hint="I return a query by object name and filter.">
<cfargument name="objectName" type="string" required="true" hint="The Transfer object name.">
<cfargument name="filter" type="struct" required="false" default="#StructNew()#" hint="The input filter of key/vlaue pairs.">
<cfargument name="orderBy" type="string" required="false" default="" hint="The optional property name to order by.">
<cfargument name="asc" type="boolean" required="false" default="true" hint="The boolean flag to specify whether to sort ascending or descending.">
<cfreturn getGateway(arguments.objectName).list(filter:arguments.filter, orderBy:arguments.orderBy, asc:arguments.asc)>
</cffunction>

If the filter param contains properties found in the object class, the gateway will use transfer's listByPropertyMap(), instead of list().

Finally, the create(), save() and delete() methods have the Transfer transaction advice applied to them. This allows one to write more complex methods that are transaction safe.

The latest Metro release (0.7) provides new behaviour to the core Service and Gateway and to the user package domain objects as well as some bug fixes, minor updates and code cleanup.  Here is a list of the important changes.

• Added a 'reap' method to core Service and Gateway that allows one to quickly discard an instance from the Transfer Cache. If no key is specified, all instances of that class will be discarded.
• Added several methods to the User, Role and Permission objects.

When I first started working on the code that is now Metro, I never suspected that development would proceed at the current pace. During that time, my approach to application development has changed and this has also had an impact on the Metro library. Therefore, I anticipate more change to Metro over the course of the next few releases. With my hope to have a solid API and process in place by the time Metro reaches 1.0.

I'm flattered by some of the recent interest in Metro and I admit that documentation is rather sparse. Unfortunately, I have not been in a position to fully document how to use Metro since it is somewhat in flux. I will, however, put together a brief project page to answer some of the questions I've been asked.

Today, I was able to get https working for localhost connections after following these step by step instructions for creating and signing a cert and updating httpd.conf and httpd-ssl.conf on Mac OS X Hints. Problem is, I need https for vhosts. When trying to connect to a local vhost over https, I encountered the following error: Error code: ssl_error_rx_record_too_long). Much more googling turned up the answer. You need to turn the SSLEngine On for vhosts. Thanks to the Ubuntu forums for that gem. Here's an example vhost that uses SSL.

<VirtualHost 127.0.0.1:443>
DocumentRoot "/Users/paul/Sites/myproject"
ServerName myproject.fancybread.local
SSLEngine On
SSLCertificateFile "/Users/paul/certs/localhost/newcert.pem"
SSLCertificateKeyFile "/Users/paul/certs/localhost/localhost.nopass.key"

DirectoryIndex index.cfm
<Directory "/Users/paul/Sites/myproject">
Options +Indexes FollowSymLinks +ExecCGI
AllowOverride AuthConfig FileInfo
Order allow,deny
Allow from all
</Directory>
</VirtualHost>