Hi Sean, I will let Kurt answer that one, because he has the Java experience. As far as tweaking the DAOs to make any new ORM fit... again, I am simply saying that having a standard bean naming convention makes it so they wouldn't have to be tweaked. I hope I am answering your question right.
In the example we posted, you can see in the Mach-II listeners where the Record naming bleeds through the service layer. We could adapt to this, and write a delegated method in the custom Record objects-- when we began to forecast what it would take to migrate a large number of our apps it struck us that a flexible bean name would benefit a variety of our apps using different frameworks. - Shannon -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean Corfield Sent: Friday, March 24, 2006 10:06 AM To: [email protected] Subject: Re: [Reactor For CF] Reactor R&D 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/ -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/
