DougHughes.net

I thought those of you out in the blog-reading world might want to know what’s new with Reactor. The answer? A whole Lot! Here’s some highlights off the top of my head:

MySQL 4 and 5 Support

Reactor has had support for MySQL 5 for a while. Sean Corfield was kind enough to donate support for MySQL 4.

Reactor is ColdSpring Configurable

Thanks to the valuable input from Joe Rinehart, I changed how configuration options can be provided to Reactor. This allows ColdSpring to configure the ReactorFactory. I’m using this in a project right now, and I’ve got to say it’s just cool to inject the ReactorFactory into my Model-Glue controllers.

Furthermore, I’ve heard rumors that ColdSpring is adding “custom factories”. I understand this to mean that you could use ColdSpring to interface with Reactor.

Transfer Objects Have cfproperty Tags

I updated the Reactor generated Transfer Objects. They now have cfproperty tags that define the data type for each of their values. This should make using Reactor objects with Flash Remoting a lot easier.

Object and Field Aliases

If you’re working with a legacy database you can now assign aliases to your objects and their fields. For example:

< object name="tblFoobar" alias="Foobar">
      <field  name="colIntId" alias="foobarId" />
</object>

This will let you address aliased objects with their aliases. For example, you could call the following code to create an instance of a Foobar Record:

<cfset FoobarRecord = reactorFactory.createRecord(“Foobar”) />

The files generated on disk pick up that alias.

Additionally, you can specific aliases on fields so if you have a column naming scheme in your database you can translate that to something more meaningful. For example, the generated FoobarRecord will have getFoobarId() and setFoobarId() methods instead of getColIntId() and setColIntId(). Queries returned from gateways on the Foobar object will also return the aliased name.

Iterator Objects

It used to be that when you created a hasMany relationship that reactor would create two methods on your Record objects, getXyzQuery() and getXyzArray() where Xyz is the name of the related objects.

This was replaced with an Iterator object. Now, when you use hasMany one method named getXyzIterator() is created. This returns an Iterator for your Xyz object. The Iterator is more powerful because it allows for filtering and sorting data, getting a query of the results, paginating the data and getting arrays of results.

Multi-Step Linked Tables

A month or so ago I added support for linking tables. For example, if you have three tables, User, UserAddress, and Address where a UserAddress has one of both User and Address and User and Address have many of each other this is what your xml would look like:

< object name="User">
    <hasMany name="Address">
        <link name="UserAddress"/>
    </hasMany>
</object>
< object name="UserAddress">
    <hasOne name="User">
        <relate from="userId" to="userId"/>
    </hasOne>
    <hasOne name="Address">
        <relate from="userId" to="userId"/>
    </hasOne>
</object>
< object name="Address">
    <hasMany name="User">
        <link name="UserAddress"/>
    </hasMany>
</object>

This would let you call UserRecord.getAddressItereator() and Address.getUserIterator() to get an iterator of these objects.

However, let’s say that you have an additional table, State. And let’s say you want to get an Iterator of all states your users are in. Previously you’d have to create your own custom method. Now, you could update your xml to look like this:

< object name="User">
    <hasMany name="Address">
        <link name="UserAddress"/>
    </hasMany>
    <hasMany name="State">
        <link name="UserAddress"/>
        <link name="Address"/>
    </hasMany>
</object>
< object name="UserAddress">
    <hasOne name="User">
        <relate from="userId" to="userId"/>
    </hasOne>
    <hasOne name="Address">
        <relate from="userId" to="userId"/>
    </hasOne>
</object>
< object name="Address">
    <hasMany name="User">
        <link name="UserAddress"/>
    </hasMany>
    <hasOne name="State">
        <relate from="stateId" to="stateId"/>
    </hasOne>
</object>
< object name="State"/>

Note that the UserRecord has many states via a two-step linking relationship. In other words, this will join User to UserAddress to Address to State and return an Iterator of matched states. You can then filter the state Iterator to return only distinct values, etc.

Linking relationships don’t care what type of relationships they link through either.

Documentation

There are about 50 pages of documentation which should help new users get started. It’s incomplete, but will be completed before a 1.0 release.

New Event Model

I recently added a simple event model to Reactor. This lets you register a method to call on any Record object when a specific event is fired on another Record. This allows you to do things like validate a user’s address when the user is validated and to save the user’s address after the user is saved.

Events can carry information around for use by the event delegates. In the case where you save an address when a user is saved, the user’s userId could be passed to the AddressRecord so that it can be set correctly.

Reactor has eight predefined events: beforeLoad, afterLoad, beforeSave, afterSave, beforeDelete, afterDelete, beforeValidate and afterValidate.

See the mailing list archives for more information.

Reactor Mailing List

The Reactor mailing list is going strong too. Last I checked there were about 90 people subscribed. The community seems to be pretty strong. Most people actually get answers to questions pretty quickly. It’s a good crowd!

To sign up, send an email to reactor@doughughes.net with a subject of “subscribe”.

Also, someone was kind enough to set up an archive of the mailing list here: http://www.mail-archive.com/reactor%40doughughes.net/. There is a lot of good information in there!

Still an Alpha

Reactor is still in Alpha. It will be for probably another month or so. I have a few more features planned which may cause the API to change slightly. However, once all features are done I will lock down the API and move into a Beta period focused on bug fixes, documentation and a Reactor project page or site. When all known bugs are fixed and the documentation is complete I’ll release a reactor 1.0.

The remaining features planned for the alpha are:

1. Updated validation.
2. Support for PostgreSQL, Oracle, and DB2.

Get Reactor

The best place to get reactor is from the public Subversion repository available at svn:/www.alagad.com/reactor. This is the most up to date code available.