Personally, I like having all that functionality in the config file as opposed to a more automated way of doing things. The advantage of course of having a lot of the information in the config file is that I can leave the CF code exactly as is (e.g. index.cfm?event=doSomething), go into that XML file and change the implementation of the "doSomething" event and the code will automatically pick that up the next time someone calls that event. I personally really like the fact that I can make a very small change in the XML file and completely change the behavior of the application, and I like the flexibility the setup offers.
Sorry if my tone came off as heated--that wasn't my intent but I realize in re-reading it that it may have been a bit more abrasive than I intended. As you mention, in the end this all of course boils down to personal choice, and I still plan to check out onTap when I have time (I promise!). At the moment having been through 2 projects with Mach-II, which is an admittedly small number, I've just had a big grin on my face every time the client has what would have been a major change and I can do it in a matter of minutes. I'm sure this positive emotional reaction has probably swayed me but it's also saved me so much time I can't help but love it. As I work with it more I may discover things about it that annoy me, but both the Mach-II projects I've done thus far have been pretty darn smooth compared to some previous experiences.
I just looked at your blog entry as well, and I think much of what you say there also boils down to personal preference. I see your point about automating some of this, but it's a trade-off: with automation you give up a certain degree of flexibility; with no automation you do more typing. I prefer the latter myself, but I certainly see your point.
Another "bottom line" on all of this is the usual "use the right tool for the job." I wouldn't use Mach-II (or probably any other framework for that matter) for a horrendously simple application that needed to be done extremely quickly. Those are usually bad projects from the outset however; they're never as simple as they seem, and you pay for quick coding later when things need to be changed. But, if such a project did exist, then Mach-II is probably a bit heavy-handed. As those "simple, quick" projects grow into larger, more complex projects, however, I've found that Mach-II keeps things almost comically flexible, which in my mind is a darn good thing. More work now, less work later is the way I look at it.
Good discussion--thanks again for getting it rolling.
Matt
------------------------- Matthew P. Woodward [EMAIL PROTECTED] AIM: CaptainJavac http://www.mattwoodward.com
----Original Message Follows---- From: S.Isaac Dealey <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Breaking the Sound Barrier? Date: Sun, 14 Dec 2003 13:38:23 -0600
Hey Matt,
I did want to provide a (hopefully less heated) response to your comments here. (Apologies to the list if I'm putting you guys to sleep with this. :)
The phrase "yields no noticeable advantage" specifically was a comment specifically about the use of the xml config file. My complaint is that, near as I can tell, I can do anything the xml config file does in the onTap framework, but without the need for an xml config file -- or for that matter without the need for a config or file of any kind. So if it's really easy to fix or manage applications in Mach-II by altering the config file, theoretically it shouldn't be any harder to do the same thing with the onTap framework by moving or renaming files. Imo (it's not humble) it's easier because it's less typing.
Also -- as a Mach-II application grows, the mach-ii.xml config file also grows with the application. There's no way to change this because of the choice of xml as the medium for configuring the application. It doesn't allow any kind of dynamic configuration (except by outside tools at development time) so I have no way to perform loops or dynamically set variables within the xml, which limits what I can do with it. There are quite a number of people who will say that this limitation is a good thing. I personally disagree.
As an example: Let's say I have a Mach-II application with 50 event-handlers. Each event-handler is at least 3 lines of xml. That's a minimum of 150 lines of code for a pretty small number of events (I suspect most applications will have a lot more than that). I believe (and I could be wrong) that I can do the same thing in the onTap framework with 0-lines of code. So given the choice between 150 lines and 0 lines to accomplish the same task I tend toward wanting to write 0 lines of code. So this is my reasoning for believing that Mach-II would increase development times for myself. It may still decrease them for other people, sheer number of lines of code not being an indicator of the time involved in a project since there's still a lot of planning, etc. involved that doesn't translate to time spent typing.
This was all gone over in greater detail in my blog (dunno if you've read it) which was even more of a rant and even less complementary to Mach-II than the article was. Admittedly, it's getting into the realm of more or less "religious" opinions about syntax that I've said several times I wanted to try and avoid.
I agree that frameworks as a rule of thumb increase execution times and initial development times in favor of later maintenance and modification. Though even if execution time isn't a decision-making factor for selecting a framework (which I think it shouldn't be), I think it's a good thing to know what your working with in terms of execution times when you're developing, so you can make better ball-park decisions about the efficiency of your code, i.e. when it's important to be maximumly efficient and when it's okay to be less efficient to save development time. I realize you already agree with this point -- I was just realizing that it wasn't something I'd mentioned in the articles, and I should probably mention it in the next one.
I also agree that hardware is cheaper than development time. (Which is something I've never really understood about people who complain about using memory for caching data or content -- imho buying more memory is less expensive than faster processors and/or load-ballancing.) I agree that 300-400 ms for an average page is plenty reasonable (the test app will probably be a bit less than that when I make it efficient). I think if Mach-II is easier for you to work with than the onTap framework then you should definately continue to use Mach-II.
Thanks for the comments by the way, I'm sure I'll be reading over them again when I go to write the next article.
> Thanks for the update--just a few comments from my > perspective. I'm a > relative newbie on Mach-II but I've used it on two > semi-large projects now > and your statement that Mach-II "yields no noticeable > advantage" is a little > off-base in my opinion. *Any* framework is going to > create longer > development times compared to the usual "display > page/action page" scenario, > and blazing-fast code can be written if you aren't using a > framework at all, > but I think perhaps your discussion is a little one-sided > since it focuses > largely on--at this point at any rate--page execution > times.
> The true benefit of using a framework comes in code > flexibility and > maintenance, not in page execution times and initial > development times. > Spaghetti code can be fast to write and may be very fast > to execute, but > maintenance is a nightmare. The "busy work" (as you call > it) associated > with Mach-II has a huge benefit in my mind, namely that > when requirements > change, or modifications need to be made in the future, > they can be done > with very little impact on the existing code.
> This is where Mach-II outshines the other frameworks I've > tried IMO, because > if something changes, you just change the details of the > event related to > that item, maybe write a new method or two, and you're > done. Very rarely do > you have to trudge through hundreds of lines of code > worrying about all > sorts of dependencies between pages and components. > Everything is extremely > cohesive and very loosely coupled, and I've found that on > the projects I've > used this on, I'm far less frustrated with changes and can > make them far > more quickly and easily than I have been able to in the > past. That's a huge > benefit, and also allows for a greater ROI on the > application in general, > because with this extremely flexibility new functionality > can be added and > old functionality can be modified quickly and easily. > This means if it's > done right very rarely will an application be thrown out > simply because it's > easier to start over than it is to modify the existing > code base.
> I don't disagree that performance is important, I'm just > pointing out that > there's a LOT more to building a successful application > than just page > execution time and initial development time. In my mind > there has to be a > balance between what the developers have to do to build > and maintain the > application and the speed with which users can access the > application. In > the two applications I've done with Mach-II, even the most > complex pages > come in at under 1000 ms under a decent user load, and > most pages load in > 300-400 ms. That's extremely acceptable in my mind. > Lowering that page > load time at the cost of abandoning something that makes > my life as a > developer SO much easier and thereby saves my company > money just isn't a > good tradeoff IMO. If faster performance is absolutely > necessary, hardware > is cheap--development time typically isn't.
> I guess my main point is that we of course always have to > be mindful of the > choices we make and how they impact performance, but the > choices we make > have a far wider impact than just performance. If we > develop something > extremely quickly that has astoundingly fast performance > but we do so at the > cost of code flexibility, then we're doing everyone > involved--both users and > the people paying for the development--a pretty big > disservice.
> Matt
> ------------------------- > Matthew P. Woodward > [EMAIL PROTECTED] > AIM: CaptainJavac > http://www.mattwoodward.com
> ----Original Message Follows---- > From: S.Isaac Dealey <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: Breaking the Sound Barrier? > Date: Sun, 14 Dec 2003 01:52:37 -0600
> It's that time again, time for the 2nd installment of > framework > comparison statistics. Both my previous article with > comparisons of > Fusebox 3 and the onTap framework, and my latest article > with > additional information about Mach-II can be found here:
> http://www.turnkey.to/ontap/docs/index.cfm?netaction=artic > les
> Assuming of course that I don't put you all to sleep. ;)
> s. isaac dealey 214-823-9345
> team macromedia volunteer > http://www.macromedia.com/go/team
> chief architect, tapestry cms http://products.turnkey.to
> onTap is open source http://www.turnkey.to/ontap
> ----------------------------------------------- > To post, send email to [EMAIL PROTECTED] > To unsubscribe: > Send UNSUBSCRIBE to [EMAIL PROTECTED] > To subscribe / unsubscribe: http://www.dfwcfug.org
> __________________________________________________________ > _______ > Cell phone �switch� rules are taking effect � find out > more here. > http://special.msn.com/msnbc/consumeradvocate.armx
> ----------------------------------------------- > To post, send email to [EMAIL PROTECTED] > To unsubscribe: > Send UNSUBSCRIBE to [EMAIL PROTECTED] > To subscribe / unsubscribe: http://www.dfwcfug.org
s. isaac dealey 214-823-9345
team macromedia volunteer http://www.macromedia.com/go/team
chief architect, tapestry cms http://products.turnkey.to
onTap is open source http://www.turnkey.to/ontap
----------------------------------------------- To post, send email to [EMAIL PROTECTED] To unsubscribe: Send UNSUBSCRIBE to [EMAIL PROTECTED] To subscribe / unsubscribe: http://www.dfwcfug.org
_________________________________________________________________
Shop online for kids� toys by age group, price range, and toy category at MSN Shopping. No waiting for a clerk to help you! http://shopping.msn.com
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe: Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
