Milestone Reactor 2.0 Alpha

Reactor 2.0? Already? 1.0 isn't even out the door yet (as of this writing)! What could possibly be planned?

Well, Reactor 1.0 is pretty nifty, but there are ways to improve it. Here are some goals for 2.0:

• Make use of ColdSpring in a manner similar to Model-Glue to configure Reactor. Currently many of the core objects in Reactor have dependencies on other objects (in the form of calls to CreateObject). This makes it hard to write meaningful unit tests for these objects. Additionally, it could allow for greater flexibility in configuring the framework.

• I may remove the usage of the XML parsing mechanism that come with Reactor (or at least XmlSearch). XmlSearch is case sensitive and makes working with the XML documents a little less intuitive than needed. For example, with a dictionary object the names used are case sensitive due to the usage of XmlSearch. Also, in the object.cfc the getXml method uses a hybrid of xml methods and traditional techniques (array/struct) to build the XML document that is transformed into reactor objects. This code could be greatly improved and simplified.

• Conventions may be configurable to allow for case sensitivity configuration. IE: in oracle and postgresql, the names are always case sensitive. This could be discoverable and/or configurable so as to allow for explicit case sensitivity (or not).

• Implement a system for optionally caching OO query results

• Add support for alternative query syntaxes (such as joins in the where statement, not just using the join/on syntax). This will allow for an adaptor for Oracle 8 and maybe other dbms too.

• Implement grouping and aggregates in OO queries.

• Consider adding more configuration details to the field tags in objects. This might allow people to specify details of fields for databases that can’t be introspected such as Access.

• Enterprise only – Create a system to allow certain methods to be run asynchronously in CF enterprise using Sean’s concurrency library. For example, update and delete methods could be run asynchronously. There may be other applications. For example, when cascading saves all the saves could be run asynchronously and then joined back into at the end to help improve performance. There’s a lot that could be done with this.

• Maybe a native system for using Flex Data Services directly with Reactor?

• Consider making iterators (and dictionary objects?) generated, thus allowing custom methods on them.

• Compound Objects - Allow for the creation of objects which span multiple tables in the database. For example, a Customer table that related to a User table might be mirged into a CustomerRecord/Gateway, etc based on configuration.

• Reactor 1.0 relies on a lot of dynamic evaluation to determine relationships. This could be moved into the generation process and made to be staticly generated.

• Support for defining multiple DSNs (to different DBMS?) in one Reactor configuration.

• If I'm adding support for a different join syntax for Oracle 8, I might as well add adaptors to non DBMS data (such as xml or delimited text files)

• Consider the generation of stored procedures (maybe optional?) for at least some platforms.

• Consider creating a sized pool of specific types of stateful objects (records and tos) to cache them when the framework loads up. This should help lessen the penalty of creating them on the fly.