Re: [Reactor For CF] Reactor R&D

Fri, 24 Mar 2006 08:41:14 -0800

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]



Reply via email to