It also isn’t really a major change
in the framework at all. Just a tweak.
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kurt Wiersma
Sent: Thursday, March 23, 2006
8:46 AM
To: [email protected]
Subject: Re: [Reactor For CF]
Reactor R&D
It isn't so much that we
want to replace Reactor in our application, but rather we want to make it
easier to move exsisting applications over to use Reactor instead of our old
handcoded DAOs. You are correct in that this isn't a show stopper but Doug asked
for feedback before that critical 1.0 release when the API gets locked down so
we though we would discuss our findings now, rather then lament later. :)
--Kurt
On 3/23/06, Adrocknaphobia
<[EMAIL PROTECTED]>
wrote:
Just in case I'm missing
somthing here... Shannon's proposal would
mean that anyone who is currently using Reactor would need to update
thier applications.
I know Reactor isn't 1.0 yet and Doug reserves the right to make any
drastic change he wants (until then), but I think this issue is too
insignificant to warrant a major change the framework at the verge or
a 1.0 release.
Pre-ORM the argument was always database agnostic-ism. "I want to
write SQL that is complaint with all databases so at the drop of the
hat I can switch from MSSQL to Oracle." The fact is... this _rarely_
happens. However, Reactor makes that extremly easy now. So now the
complaint is "I want to switch out my ORM framework without having to
do any work at all".
Pretty lame if you ask me. I really don't mean to chastise, but what
sort of 'enterprise applications' are these that you have to second
guess and replace core aspects on the fly?
-Adam
On 3/23/06, John_Farrar <[EMAIL PROTECTED]>
wrote:
> I see what he is saying. His concept is to configure the abstract
interface
> for the generator. (Might be phrasing it wrong... but that is what it
sounds
> like.) This would not be an issue of rewriting reactor to fit their
> situation. It's writing reactor to fit many situations, while maintaining
a
> default. This seems like it would be a good way to satisfy internal coding
> requirements and enhance the speed of integration for many companies.
> Certainly that proves out to not be selfish request on Shannon's
part. It
> makes a lot of sense.
>
> The big question for me is how to do it flexible and meaningful Shannon. I
> am for the concept... but how would you achieve it? It seems the only way
to
> achieve it in my flash of creativity would be to hardcode different
options.
> That means that it is more custom and less flexible. In fact that would
mean
> that every time a new standard came out it would have to be refractored to
> integrate that generation option and tested again. Now if there were a way
> to implement a generator template then you might have something. To my
> knowledge this technology is still lacking. So until someone has a robust
> template generator technology I don't see how Doug can comply with the
> request without creating something custom at this time.
>
> John Farrar
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf
> Of Doug Hughes
> Sent: Thursday, March 23, 2006 8:17 AM
> To: [email protected]
> Subject: RE: [Reactor For CF] Reactor R&D
>
> 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/
>
>
>
-- 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 -- 
