Nathan,
I didn't see anything jerky in what you said. I'm glad you shared
your two cents. I'd love to get more feedback from more people....
but frankly the silence on the list may speak volumes.
And who knows if ORM will actually even be in CF 9? And, who knows if
the hypothetical ORM in CF 9 will be any good? Seriously. Adobe has
a very, very, bad habit of doing things about 80% of the way. The
other 20% are just left for us to pull our hair out about. Think
flash forms, ajax features, pdf features. I mean much of anything
above the basics in those feature sets makes me want to scream. Oh,
and let's not forget about the thousands of existing applications that
use transfer or reactor.
Anyhow, having reactor not be languishing is better for us all, I
believe. I just can't do it on my own.
Doug Hughes, President
Alagad Inc.
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
888 Alagad4 (x300)
Office: 919-550-0755
Fax: 888-248-7836
On Wed, Sep 17, 2008 at 7:01 PM, Nathan Strutz <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Well I've been thinking about it for a few hours now since you
dropped this, and I'm sure we've all got some thoughts, so I'll
just voice what nobody wants to hear. Voice of opposition or
whatever. No caffeine makes me fussy.
I guess the big question is: will CF9 make custom ORMs obsolete? I
know Mark Mandel has been fighting this battle, too, arguing the
legacy server battle and the fact that our ORMs are here now,
whereas Adobe's is not out yet.
For Mark Drew taking over the project, yes, Doug, you've done an
amazing job but you're too busy and maybe we need a new leader if
this project is going to go anywhere. You know I'm all for
anything that pushes Reactor forward.
Another thing we don't want to hear: I would rather Mark spend all
his time making CFEclipse better. Yeah that's a selfish statement,
sorry. But hey, if Mark Drew says he can do it, I believe it, that
guy is Superman x3.
Another quesiton nobody wants to ask: Is CF9's IDE going to kill
CFEclipse? Probably not if it costs money. Probably if it's free.
The idea of Reactor "lite" is fantastic. What if a bunch of the
features were separate downloads - database introspection (Reactor
Base), various object generation (Reactor ORM), a custom version
of Validat (Reactor Validat, or something), OO Queries (Reactor
Query Code) and you can build your own with what feature you want
(Have you seen jQuery UI download builder?). How about a scaffold
form generator add-on.
Why doesn't Reactor generate its own config file when I know it
can read my database?
As nice as ColdSpring is, I don't know if that's the answer. If
you're looking for ways to switch out core components, just make a
config file or a section in the reactor.xml file and implement a
simple abstract factory. I could, however, see reactor creating a
coldspring config xml file for ColdSpring 1.2's new <include ...
/> tag, where Reactor could manage that file and we could just
include it along with our other beans. That would be a big win.
Like you said, we've all got ideas.
I'll shut up now, I know I've been kind of a jerk and all on this
subject. Anyways, Mark would be great. I don't really know who
else is using Reactor that has the chops, experience and desire to
run the show.
nathan strutz
[Blog and Family @ http://www.dopefly.com/]
[AZCFUG Manager @ http://www.azcfug.org/]
On Wed, Sep 17, 2008 at 8:45 AM, Doug Hughes <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi everyone,
It may or may not be obvious that Reactor has been, shall we
say, idle under my oversight. Honestly, my focus is on my
business and things that directly impact it. Reactor is only
in my periphery these days and, as a result, support and
momentum behind the project has faltered.
The CF community focus really has been on Transfer and its
features. And, though Transfer is a terrific product and we
have used it on some projects here at Alagad, it's not the end
game.
Beyond that, there's a lot that remains that can be done with
Reactor. There are ideas I've had for a lite version, or a
ColdSpring based architecture that would allow for
customizations of the core, and so much more. And I know many
of you have ideas. Not to mention issues that need to be
resolved.
My realization is that I personally don't have the time or
inclination to get into Reactor code any more. And so, for a
while, I've been looking for someone to take over as a project
manager for Reactor. I've asked Mark Drew a few times if he'd
be willing to chip in and today he hesitantly agreed.
However, we both want to talk to the community of Reactor
users before making the official decision. Do you think you
or someone else might be a better (or simply different)
choice? If so, please speak up.
If Mark does take over the project then he'll presumably be
working with you, the community of Reactor users, to come up
with a plan for the future of the project. I also anticipate
that the development of the project will become much more open
and inclusive than it has been in the past. (Maybe some of
the mess in OO queries can be cleaned up?)
Anyhow, I just wanted to open this up for discussion. Let's
hear what you have to say.
Doug Hughes, President
Alagad Inc.
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
888 Alagad4 (x300)
Office: 919-550-0755
Fax: 888-248-7836
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- -- --
Reactor for ColdFusion Mailing List
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- -- --
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- --
Reactor for ColdFusion Mailing List
[EMAIL PROTECTED] <mailto:[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/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- -- -- --
