This one thing I’m considering…. Maybe.   BIG maybe.

 

Doug

 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jared Rypka-Hauer
Sent: Friday, March 24, 2006 11:41 AM
To: [email protected]
Subject: Re: [Reactor For CF] Reactor R&D

 

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

http://www.web-relevant.com

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.

 

- Shannon

 

-----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:

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]

 

 

 

 

 

 

 

 

-- Reactor for ColdFusion Mailing List -- [email protected]

 

 

 

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

Reply via email to