Ok, I know I said that we were feature complete, but some things became very compelling to me and I just took care of them.  So, here’s some recent updates I’ve made:

 

Added addObjects() to the reactor.config.config object.  This method can be used to load additional object blocks in multiple reactor.xml files into your configuration.  This was inspired by (and largely uses) the code that Sean wrote as described in this blog entry: http://corfield.org/blog/index.cfm/do/blog.entry/entry/Web_Services_ColdSpring_and_Reactor.  Essentially you can now split up your configurations.

 

I’ve been playing around with “action packs” (the include tag) in Model-Glue and realized that to allow for completely separated includes I’d need to also allow the object tags in other reactor.xml files to define where those files will be generated.  Thus, if I have an action pack named “foo” I could have a /foo/data directory where all the objects specific to that action pack could be written.  So, the object tag now has an optional argument “mapping”.  You can use this to define where that block of object’s generated files will be written.

 

Lastly, I’ve been annoyed by reactor’s one-to-one relationship between objects and tables.  This means that if you have any lookup tables you need to get values from you need to do something like Foo.getBar().getName() to get foo’s bar name.  To get around this I added a new usage for field tags.  Here’s an example:

 

<object name="Foo">

            <field source="Bar" field="name" alias="barName" />

 

            <hasOne name="Bar">

                        <relate from="fooId" to="fooId" />

            </hasOne>

</object>

 

Now Foo records will be generated with a read-only method called getBarName() which will return bar’s name.  This is not done via a separate query.  In fact, the gateway objects have been updated so that they return they automatically join to the Bar object and get the value when reading from the database.  So, records and gateways just work.  However, you can’t set the field.  To set the field you’ll need to call Foo.getBar().setName(“blah”) as always.  However, the field will automatically return the right data as that bar object changes.

 

I also finally got latest on the changes Beth has been sheparding into the framework.  I’ll fix (or report) and new bugs I run into related to that.

 

Share and enjoy!

 

Doug


-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Reply via email to