|
This one thing I’m considering….
Maybe. BIG maybe. Doug From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jared Rypka-Hauer You know, it seems that this could be as simple as adding: <defaultRecordGetter name="Record" /> to the XML... then in the ObjectFactory, as simple as: <cfif len(variables.config.getDefaultGetter())> <cfloop collection="#GeneratedObject#"
item="m"> <cfif right(m,len(variables.config.getDefaultGetter()) is
"Record"> <cfset
GeneratedObject[left(m,len(m)-len(variables.config.getDefaultGetter())] =
GeneratedObject[m]> </cfif> </cfloop> </cfif> ...just before the cfreturn GeneratedObject. You'd also have to add a
handler to config.Config to handle the extra property (which I haven't given
the best name here... I hate naming XML tags! It's hard to find the right
semantic for some things.) And really, that would be the only place the code for the framework has
to change. I don't see this as being a huge issue for the framework, and at the
same time it's such a trivial change that adding it and maintaining it
shouldn't be difficult if you really thought it would be that useful... might I
suggest adding it, testing it, and then coming back in 3 weeks and saying
"well, we did that one tweak and wow, it sure did work good!" or
"it sucked and we hate it" but... put it into production and see what
happens. Just a few more ramblings. :) Laterz, J ------------------------------------------------ Jared C. Rypka-Hauer Continuum Media Group LLC Member, Team Macromedia -
ColdFusion "That which does not kill me
makes me stranger." - Yonah Schmeidler On Mar 24, 2006, at 10:17 AM, Shannon Jackson wrote:
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. - -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
On Behalf Of Sean Corfield Sent: Friday, March 24, 2006 10:06 AM Subject: Re: [Reactor For CF] Reactor R&D On 3/24/06, Jared Rypka-Hauer <[EMAIL PROTECTED]> wrote:
not
I asked this and Kurt indicated they'd done this in Java for Hibernate etc but Reactor. I'd like to hear a good justification for that.
how
the
This was also a specific point I made and didn't get an answer on.
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/ |
- RE: [Reactor For CF] Reactor R&D Shannon Jackson
- Re: [Reactor For CF] Reactor R&D Sean Corfield
- RE: [Reactor For CF] Reactor R&D Shannon Jackson
- RE: [Reactor For CF] Reactor R&D Shannon Jackson
- Re: [Reactor For CF] Reactor R&D Sean Corfield
- RE: [Reactor For CF] Reactor R&D Peter Bell
- RE: [Reactor For CF] Reactor R&D Shannon Jackson
- Re: [Reactor For CF] Reactor R&D Jared Rypka-Hauer
- RE: [Reactor For CF] Reactor R&D Shannon Jackson
- Re: [Reactor For CF] Reactor R&D Jared Rypka-Hauer
- RE: [Reactor For CF] Reactor R&D Doug Hughes
- RE: [Reactor For CF] Reactor R&D Doug Hughes
- Re: [Reactor For CF] Reactor R&D Jared Rypka-Hauer
- RE: [Reactor For CF] Reactor R&D Doug Hughes
- Re: [Reactor For CF] Reactor R&D Peter J. Farrell
- Re: [Reactor For CF] Reactor R&D Sean Corfield
- Re: [Reactor For CF] Reactor R&D Kurt Wiersma
- Re: [Reactor For CF] Reactor R&D Kurt Wiersma
- RE: [Reactor For CF] Reactor R&D João Fernandes
- RE: [Reactor For CF] Reactor R&D Chris Blackwell
- Re: [Reactor For CF] Reactor R&D Walt Sparrow-Hood

