For those who are interested, the next version of Tartan (1.0.5) is coming soon. In the last couple of months I have gone ahead and made a number of changes, and I figured this would be a good time to introduce them.

Property Manager - tartan.core.PropertyManager

This has been added to address the need to have access to service-level properties from the LocalService class and any Command defined for that service. This enables command handlers to access service data without having to explicitly pass it around through command arguments. Before, if two or more commands needed to access the same model, it was the responsiblity of the calling service class to make sure it passed it in. Now properties can be declared in the configuration XML, set by service methods, and inside commands. The PropertyManager class has a number of methods that give it the general behavior of a struct/map. These include methods such as getProperty(), setProperty(), getProperties().

Here is an idea of how it looks in the XML configuration:

<service name="SERVICENAME" class="CLASSNAME">
   <properties>
      <property name="prop1" value="value1"/>
      <property name="prop2" value="value2"/>
   </properties>
   ...
</service>

ServiceContext - tartan.context.ServiceContext

This class was created to consolidate the management of the various factories that are used with a service and made available to command handlers. The CommandContext used to be initialized with the factories themselves, and the it accessed them directly. Now the CommandContext is initialized with the ServiceContext and all access to the factories is done through it. Additionaly, the PropertyManager is also accessible only through the ServiceContext.

There is a one-to-one relationship between service objects and ServiceContext objects. It is planned for the near future that all access to a service object will be through its ServiceContext. This includes remote calls, local proxies and even between individual services. This will enable finer-grained control over the lifecycle of the service, including how it is called.

User-defined Factories - tartan.core.Factory (abstract base class)

One of the limitations placed upon Tartan users was that all objects/factories had to be those provided by the framework. Existing classes did not fit cleanly into the services since it was up to the LocalService class itself to create and manage the creation of those classes/objects. With the addition of user-defined factories, a user of the framework can create a simple wrapper for their own factory classes and declare it for the service. One example of this is the wrapper for a ColdSpring bean factory which can be found at "tartan.contrib.ColdSpringBeanFactory".

The only requirement is that the wrapper class extends the class "tartan.core.Factory" and it implements the "getObject()" and "getObjectNames()" methods. It can create any type of object that ColdFusion can work with. The factory is available via the ServiceContext object's "getObject()" method.

Here is an idea of how it looks in the XML configuration:

<service name="SERVICENAME" class="CLASSNAME">
   ...
   <factory name="FACTORYNAME" class="CLASSNAME">
      <parameters>
         <parameter name="param1" value="value1"/>
         <parameter name="param2" value="value2"/>
      </parameters>
   </factory>
   ...
</service>

A number of changes have also been made to some of the existing classes as well, a couple of which have been renamed for greater clarity. First, the class "tartan.command.Event" was renamed to "tartan.context.Command", and the class "tartan.command.Command" was renamed to "tartan.command.CommandHandler". Basically, a Command is a logical name with a set of named values, and a CommandHandler is responsible for processing that command object. For me, the Event class never really fit since in the context of commands. For backwards compatibility the old classes will work the same as before, however, any new code should use the new classes.

configure() method

Additionally, the method "configure()" has been added to the following classes:

• tartan.service.LocalService
• tartan.command.CommandHandler
• tartan.data.DAO
• tartan.vo.ValueObject
• tartan.exception.ExceptionHandler
• tartan.core.Factory

This method is a place for user-defined initialization. Before, the only place for this was in the "init()" method and then it was up to the user to call "super.init()" which is less ideal and places an unneeded dependence on the implementation of the underlying abstract class.

Flash Remoting

There have also been some fixes for Flash Remoting as well. It seems that before service method arguments were not being properly converted from ASObjects to CFCs. Additionaly, arrays of CFCs/ASObjects are now properly handled in the conversion process.

XmlReaders/Builders

The various dynamic factory classes have handled the reading and interpretation of the Xml configuration. One of the changes I have made for this release is to separate the Xml configuration from the construction of the factory classes. Now, the reading of XML configuration has been delegated to the classes in the "tartan.xml.readers.*" package, and they produce an intermediate configuration. Also, the creation of the various factories has been moved into the classes in the "tartan.builders.*" package. The configuration generated by the XmlReaders can be fed into the Builder classes to produce the objects needed for each service. One of the benefits of doing this is that the dynamic factories are now simpler since they no longer deal with reading of XML. Additionally, it should make it easier to add different sources for the service configuration.

Sample Applications

There have been a couple of sample applications added to show some of the newer functionality. They are listed below:

• Contact Manager (MachII, Flex)
• Task Manager (Fusebox)

The other sample apps have also been updated.

Anyhow, these are most of the changes in this release candidate. I am interested to hear what you have to say.

Until I get the code in a single download, you can download the framework from the project's CVS repository. If you are interested in checking it out, you can find it here:

CVSROOT
:pserver:anonymous@cvs.sourceforge.net/cvsroot/openxcf

MODULE
tartan_framework

TAG
Tartan-Framework-1_0_5-RC1

Well, I have been invited to speak at the Fusebox Conference this year on Tartan. I will be giving an overview of the idea of service oriented architecture and how Tartan fits into the landscape of ColdFusion frameworks including Fusebox, MachII and ModelGlue. If you currently use one of these frameworks or you build RIAs with ColdFusion backends and you are planning on attending the conference this year, then I recommend you check it out.

A couple of hours ago I gave a presentation introducting Tartan via Breeze. If you weren't able to watch it live, you can watch a recording.

It's amazing what you discover about your code when you try to write unit tests for it after the fact. When I was developing Tartan some months ago, all the testing I did was manual. I just checked that it acted the way I wanted to under certain configurations, but as I moved forward, some tests would no longer work since the code they were testing no longer existed or worked in a different manner. Really, I was testing the code to validate ideas and ways of doing things.

The biggest problem, though, was that I was not really testing small units of functionality like method calls, but in larger units of general behavior. How then would I know if something broke as I made changes to the core framework code? The simple answer is that it would throw some exception someplace and I might know how to fix it. But really, I wouldn't know since I had nothing in place to do any sort of regression testing. So far, that has worked.

A couple of weeks ago, I decided that this needed to change. As Tartan has moved forward, I have gotten a lot of requests for changes, bug fixes, and enhancements. Many of these changes aren't so simple and require a good idea of how things are put together. Some people have sent me code that makes some of these changes, but it is really difficult to see how these changes affect the rest of the code.

So, I decided that before any important changes were made to the framework, there would be unit tests to verify all of the current code. It was a tough decision since there is so much code to test and there are a lot of things I would like to do with the framework. There are several things that guided my decision. First, I really need to know exactly what the code is doing and how it can break. The only way to do this is through specific and repeatable tests. Second, as more people use the framework and the code evolves backwards-compatibilty becomes more important that ever. The only way to track this is to have tests that guarantee pre-existing interfaces and behavior. Third, I am not the only person that would like to make contributions to the codebase. As I stated earler, several people have expressed interest in improving the code and have submitted code highlighting these changes. Without any formal unit tests in place, it is more difficult for anyone involved (even me) to know if the change interferes with anything else or just doesn't work. Additionally, any new code would be given its own set of tests that run with all the others.

So far, I have written about 45 tests using cfcUnit, and I am not even half way yet. I have however learned quite a bit about some of the current weaknesses that exist in my code, and I have even discovered some rather subtle bugs that I didn't really see in my earlier testing. I have written tests for these and fixed them. I also see a lot of things I really want to change, and that has been the hardest part in a way. Part of me just wants to go ahead and introduce new features and move things forward, but I realize that in order to move forward I have to know where I stand. I can't do that without the tests. So, I make a list and move on to writing more tests.

I have been asked when the next release of Tartan will be coming out, and my answer is after these tests are written. It is an investment in the future of the framework and the community of people use it and want to contribute to it.

Its been a little while since my last update to the Taratan framework code, but I have been doing a bunch of clean up of minor bugs and some improvement in the MachII integration. You can update it at the following address: http://sourceforge.net/project/shownotes.php?release_id=316822

I just got finished with my first go at a web site for the Tartan framework. It is a work in progress, but you have to start somewhere. It can be found at:

http://www.tartanframework.org

Much of the content has been contributed by Jared Rypka-Hauer, so if you have anything you want to see there, let me know and we can talk...

Anyhow, check it out!

There is a new set of files for Tartan. Check it out:

http://sourceforge.net/project/showfiles.php?group_id=100854&package_id=141144

Oh, and let me know if you have any problems.

There is a new blog entry by Jared Rypka-Hauer who has boldly gone ahead and installed Tartan. In his article, Command-driven service framework for ColdFusion, he recounts the trials of installing and configuring the framework and sample application and finally his insights into the advantages of encapsulation offered by the framework.

A couple of people have asked about any possible mailing list, so I went ahead and created one at topica.com. The main page for the list can be found at http://lists.topica.com/lists/tartan. You can join the list from this page.

Ok, I just went ahead and put the code up to SourceForge as a downloadable zip file. You can get it here: http://sourceforge.net/project/shownotes.php?release_id=297551