We certainly don't want to change Reactor only because of our application naming convention. We follow the java bean naming convention in our business objects. So we have getter and setters for all our properties. So if we have an address object inside a user object we have a getter and setter called getAddress() and setAddress(). I thought that this is a standard naming convention. Is it your experience that this is not the case? If it isn't the case then I guess we don't have a good enough point to get Reactor change the auto generated methods like getAddressRecord() to getAddress().
I maybe trying to hard to compare things to the java world here. In the Java world I can swap out Hibernate, Castor, and now even EJB3 just by adjusting my DAOs. I can do this because both those frameworks support the standard java bean naming conventions.
I think code example might better help us show our point. I will work on putting one together.
--Kurt
On 3/23/06, Doug Hughes <
[EMAIL PROTECTED]> wrote:
So you're asking to have Reactor changed to better fit your application?
Isn't that a bit extreme?
Either way, show us some examples. Make it clearer.
Doug
-----Original Message-----
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf
Of Shannon Jackson
Sent: Thursday, March 23, 2006 8:08 AM
To: [email protected]
Subject: RE: [Reactor For CF] Reactor R&D
Hi Sean,
On the contrary, removing the unnecessary "Reactor" appendage does in fact
completely abstract Reactor. We are try to explain that by not having that
there we can slip Reactor into existing apps with no modifications to the
application above the service layer.
So, simplifying Reactors embedded bean calls makes a world of a difference
when it comes to migration. It is so close to being abstracted as it is, we
are trying to suggest that this small change would make Reactor better than
perfect. Beans are beans and we should be able to name them what we want no
matter what is going on inside of them.
- Shannon
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
Of Sean Corfield
Sent: Thursday, March 23, 2006 12:34 AM
To: [email protected]
Subject: Re: [Reactor For CF] Reactor R&D
On 3/22/06, Doug Hughes < [EMAIL PROTECTED]> wrote:
> Something that jump out are the point about the "record" convention (is it
a
> convention or is it just part of the API?) in Reactor. I doubt that
you're
> going to have much consistency between different ORM frameworks in their
> approach to problem solving. This means that another ORM framework would
> probably have it's own API and it's own set of issues.
Having worked with four of the ORM frameworks - and written them up in
my Objects & Persistence talk (download it from my blog) - I can only
agree with Doug here. Each framework exposes a different API, a
different naming convention. I really don't think it is realistic to
expect to be able to simply swap out one ORM for another. I do not
think that changing the naming conventions in Reactor will help you
here - the naming conventions will be different in each framework so
you will still need to either write an adapter for each or modify your
code.
I think the Reactor naming convention is clear and appropriate -
having multiple methods called getXyz() that return a record in one
case and an iterator in another case would be a terrible idea.
--
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/
-- 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/
