Yeah, Mach-II looks pretty sweet. When Hal first described it on one of his Occassional Newsletters, I was quite stoked. However, it's been a little too dynamic for me to justify spending much time playing, as I won't get to use it in practice. One of these days I'll get around to giving it a full-fledged test drive, which will be very interesting.
This is quite possibly a mental block on my part, but I like my procedural front-end since that's the way the web works. Persistance, however shortlived, is what makes objects worthwhile, and the web doesn't have that at the UI level. You can write procedural code using objects, and it'll work just fine, but that doesn't mean you should. I spent hours arguing with a friend who does exclusively .NET stuff about event driven web apps. As long as you have to reload the entire page, procedural seems like a much more logical way to go. You start at the top of the page, and go until you get to the end of the page, and then stop. The procedural shell can be remarkably thin, but my opinion is that it belongs there. There is never a need to fire an event to display the header of an HTML document. It always happens once per request, and while it might not be the first thing done (it isn't in FB3, and sounds like it doesn't have to be in Mach-II), it happens at the same spot in the request processing procedure. That "driven by an XML file" statement pretty much gives it away. If it's declarative, the order is fixed when it's coded, not runtime, and is therefore procedural. I'm curious. At a very high level, is this a fair description of what happens in a typical Mach-II request cycle? 1) Fire an event (click a button/link) 2) Let the event handlers do whatever, possibly firing additional events 3) get page content 4) add layout(s) 5) return the page to the client To me there is a very distinct line between the first two steps and the last three steps. What the first two steps do is totally unknown until it happens. It might go 1-2, or it might go 1-2-1-2-1-2, or possibly 1-2-1-1-2-2. Who knows. The last 3 steps may be influenced by variable values, and there may even be looping over step 4, but I know exactly what's going to happen, and in what order (3-4*-5). "What about Struts? It's not procedural" I suspect this question will be raised, so I'm going to answer it now. Struts makes this separation very well. It has a purely OO controller that uses an XML file to provide a procedural skin to the outside world. Everything else happens with a network of objects, and then when it comes time to actually handle the HTML, it hands off processing to something else as defined in the XML file, usually a JSP page. The procedural skin simply says "fire this event, then send it over there". The 'over there' takes care of all the procedural crap pertaining to crafting a response for the client. Beautiful. Now, before anyone jumps on my back like a rabid monkey, I don't have a better solution to this dichotomy, and if a solution is to be found, it's undoubtedly going to come from someone a lot smarter than I. It is my humble opinion that using an object system to do procedural work is bad, and if both types of execution are needed, formal separation between them is a a desirable characteristic for an app to have. Well, another overly long email on a day full of them. cheers, barneyb --- Barney Boisvert, Senior Development Engineer AudienceCentral [EMAIL PROTECTED] voice : 360.756.8080 x12 fax : 360.647.5351 www.audiencecentral.com --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.501 / Virus Database: 299 - Release Date: 7/14/2003 ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
