Entries Tagged as 'ColdSpring'
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>
When developing OSS software, one should endeavour to maintain backward compatibility with each new release while adding improvements and new features (and fixing bugs). The current Metro release (0.6) is a significant departure from previous releases. While it maintains backward compatibility for service and gateway methods, it also provides improved support for validation rules and contexts thanks to a huge contribution from Matt Quackenbush. The changes are designed to promote building rich business objects. I removed some of the setup dependencies which I was unhappy with, and now use "import" for ColdSpring and "include" for Transfer to simplify configuration. Lastly, I have also re-organized sample code and support documents. Here is breakdown of the items requiring modification to use Metro 0.6.
Wiring the Coldbox Logger Plugin To An AOP Logging Advice
Coldbox , ColdFusion , ColdSpring , AOP 1 Comment »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.
Using Metro - A Transfer ORM Audit Observer
Metro , Transfer , Ideas , ColdFusion , ColdSpring 1 Comment »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.
Recent Comments