On 3/24/06, Jared Rypka-Hauer <[EMAIL PROTECTED]> wrote: > Since you have to tweak your DAOs to make any new ORM framework fit, why not > just tweak for Reactor too?
I asked this and Kurt indicated they'd done this in Java for Hibernate etc but Shannon indicated they didn't want to do it for ColdFusion and Reactor. I'd like to hear a good justification for that. > I suspect the likely answer is "because the way Reactor works now isn't how > Java works." Bummer. This one annoys me. :) Reactor's API is set up to > differentiate between the Iterator and the Record, so, since getNRecord() > and getNIterator() both exist on the objects in question you're asking to > turn getNRecord() into the default and, IMO, breaks the consistency and the > stability of the framework's API. This was also a specific point I made and didn't get an answer on. > Macromedia ran a slightly > modified version of Mach-II for a long, long time... that may be an option > for you guys as well. Just to clarify: - we changed the DTD to allow plugins to be declared with filters, above the event handlers (I felt - and still feel - that's a better order in the XML file; I don't recall what 1.1.0 did in this area but I remember it being discussed). - we developed a custom invoker to implement the equivalent of resultArg= (but based on resultKey=) and we kept it in the core invokers directory. The former is essentially "outside" the framework and only affects XML validation in our IDE (the changed DTD is not part of the core and its use is optional anyway). The latter we actually dropped after a while and now 1.1.0 supports such an invoker so we've integrated a standard 1.1.0 core now and may use the new core invoker going forward. -- Sean A Corfield -- http://corfield.org/ Got frameworks? "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/
