Everyone- I just want to back Joe up on this. He and I have had long conversations about this topic. For the most part, I agree with him.
I think it's important that everyone realizes that, in the end, the buck stops here. I'll be making the decisions about what does and does not make it into the framework. If you can't take this, you're welcome to branch Reactor it into another project (if you really think it's a good thing). That said, I haven't even had the time to consider any of recent suggestions closely. If you read my blog you'll see I'm a bit occupied with building a new house, working with busy clients, having another kid, etc. For now, this necessitates a slower approach to Reactor. Don't worry. I'll get to these things before too long. When I do, I'll decide if they'll make it into the framework and how they will be built. For the most part, I have a pretty good idea how I'm going to be building out the framework and I want to keep certain patterns in mind as I do it. I don't mind accepting patches or suggestions. But, at least for now, I'm going to be holding Reactor close to my chest. Here's what I *do* need help with: 1) Documentation. If you want take ownership of a section of the documentation, I'll give you guidance on this. 2) Testing. I wish I knew of a way to write an automated testing framework that would test all the functionality of Reactor on all possible CF and BD versions, supported OSes, and supported DBSM. (If someone wants to take that up, I'll add virtually any features they want! ;) ) 3) DBMS support. I'd graciously accept support for Oracle, PostgreSQL, DB2 and Access. This is not very hard to do! If you take this on, I'll buy you a few big beers next time I see you. 4) A better way to track submissions so I can thank people who contribute in the source code. 5) An Ant script to build and deploy a reactor zip to my server at the click of a mouse. 6) Blogging. I wish people would blog more about the features of the system and their various opinions, favorites features, examples, etc. (Though I'm sure this would be a double edged sword.) There's more, I can't think of it yet though. So, the moral of the story is: give me time. Doug -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Rinehart Sent: Friday, February 10, 2006 7:42 AM To: [email protected] Subject: Reactor For CF Remember KISS Hey guys, I think it's great that we're starting to have some serious interest in open-source ColdFusion frameworks, but I think we need to keep the KISS (Keep it Simple, Stupid!) principle closely at hand, especially when suggesting enhancements. As someone who's written a few frameworks, I've gone astray once or twice and it's cost me. Model-Glue has things that probably shouldn't even be there (controller-based caching, anyone?). This has cost me "ugliness" of the API in some places, higher maintenance costs, and some parts of the framework (the controller) being "fatter" than they should be - all because I forgot KISS, and got wrapped up in what my code *could do for a few* instead of what it *should do for the many.* I get code submissions for Model-Glue on a weekly basis, and I turn 99% of them down. I'm not trying to be mean: they're usually very good ideas and very functional *for the person submitting them,* but it's not worth the cost to the rest of the Model-Glue community to have to learn a new aspect of the API for something they'll probably never use. For a framework to be successful, I think its API needs to be kept both as small and consistent as possible (or you get PHP). Addition of new functionality should be approached very cautiously. What I like about Reactor is a lot of what I like about Model-Glue: you barely even need to read the manual to use it effectively, because things just make sense (if you understand why you're using the framework and what it provides to begin with). The more that gets added to it, the less true this becomes. I'm working on Model-Glue Unity (2.0) right now, and KISS literally keeps me awake at night. There's something I want it to accomplish, and while I have all the tools and the code in place, it's requiring an extra level of complication not present in Model-Glue 1.x and it really, really worries me. I've spent five times as much time thinking about how to make it easy than I have getting the thing to work (I'll blog about that later today). -Joe -- Get Glued! The Model-Glue ColdFusion Framework http://www.model-glue.com
