I'm familiar with all the versions of Fusebox, but I never particularly
liked any of them once Fusebox 2 came out. Can't pin down my exact reasons,
but it's was essentially a problem of being constrained by the framework
rather than enabled by it.

I have worked extensively with Spectra and written a large content
management system from scratch using some of the principles from there. I
helped to write the fourQ data persistence layer for Farcry and am still
involved with the continued development.

Last year, before Mach-ii appeared, I architected a system for Tourism
Queensland in Australia using MVP. The architecture I developed for them is
called Batfink and has a few of the same principles as Mach-ii. The app is
separated into Model, View and Presenter. The model and view are close to
what you would probably do in a Mach-ii app, but the presenter layer in
Batfink works differently to how the core files work in Mach-ii.

As a comparison, I'd say that Mach-ii provides a far richer set of options
for how to build any app than any version of Fusebox. I definitely prefer it
to Spectra and the CMS I built. Partly because it allows you to build more
than a content management system, and partly because it's more lightweight.
I haven't decided yet on whether I prefer it to Batfink. So far it hasn't
forced me to make any architectural decisions "because that's the way it
works", but I'm quite early on in this project, so we'll see how that pans
out as I get into the more complex stuff.

Once you get the hang of how it works, it is pretty easy to develop with,
and it should be pretty easy to make changes to a Mach-ii app for
maintenance purposes. The one thing I'm wondering about is how hard it would
be to correct a major architectural mistake. My suspicion is that a lot
would depend on how well you stick to some of the guiding principles of OO
(and any software development for that matter). Namely: increase cohesion
and decrease coupling. As long as you've got that right, your architectural
screw up should be pretty well isolated from the rest of the app and not too
difficult to fix.

Spike

>-----Original Message-----
>From: 
>[EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED]
>o.uk] On Behalf Of Sam Westlake
>Sent: Tuesday, April 20, 2004 7:41 AM
>To: [EMAIL PROTECTED]
>Subject: RE: [ cf-dev ] Mach II
>
>Did you tackle Fusebox before getting involved with mach-ii? 
>Or any other frameworks for ColdFusion?
>
>How do you find they compare with mach-ii as a developer? 
>
>-----Original Message-----
>From: Stephen Milligan [mailto:[EMAIL PROTECTED]
>Sent: 20 April 2004 16:35
>To: [EMAIL PROTECTED]
>Subject: RE: [ cf-dev ] Mach II
>
>I'm about ankle deep in a project right now where the client 
>wanted me to use Mach-ii. If you understand OO programming 
>you'll find a lot of what's going on very natural and 
>intuitive. If you haven't done much in the way of OO before 
>you'll have a bit of fun wrapping your head around what's going on.
>
>It is a true framework in that it provides pre-written code 
>and modules.
>That pre-written code forms the controller part of an MVC 
>methodology. You write the model and view yourself and, using 
>the XML config file, tell the controller the sequence of 
>actions you would like to take for any given request.
>
>The view is generally plain old cfm files that generate HTML, 
>and the model tends to be CFCs.
>
>You might have a bit of fun trying to get started with it 
>because there isn't really a 'hold my hand' guide. The sample 
>apps are relatively simple, so you can be left scratching your 
>head wondering how to go about implementing a more complex 
>project. If that's the case you should probably go have a look 
>at http://www.mach-ii.info. The source code for that site is 
>available online for download and is a more solid example of 
>how a real world mach-ii app might be written.
>
>One of mach-ii's strengths also happens to be a bit of a 
>weakness for the beginner. There are just so many different 
>ways you could approach any given problem that it's hard for 
>anyone to give you an answer on the _right_ way to do what you 
>want to do. Once you get over that it's a very solid system 
>and I expect I'll be using more of it in future projects.
>
>Some things to be aware of though:
>
>Having debugging enabled in the ColdFusion Administrator will 
>make your app _crawl_. I mean it will be slower by a factor of 
>up to 10 times, so you probably want to have it turned off 
>most of the time and turn it on only when you have a specific 
>problem to track down.
>
>The core files are meant to be a black-box solution. i.e. 
>You're not supposed to go poking around in there to see if 
>there's a way to take advantage of some quirk of how they work 
>in your apps. That makes sense because a new release could 
>come out at any time and you don't want to have that break 
>your existing apps.
>
>If you don't really know very much about OO and design 
>patterns before you start, make sure you have a reference of 
>some kind handy when you look through the code for the sample 
>apps. Especially the source code for www.mach-ii.info. It has 
>some good examples of several design patterns, but if you 
>don't know that the patterns exist it might be a bit hard to 
>figure out what exactly is going on, and more importantly why 
>the code is written the way it is.
>
>HTH
>
>Spike
>
>>-----Original Message-----
>>From: 
>>[EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED]
>>o.uk] On Behalf Of Robertson-Ravo, Neil (RX)
>>Sent: Tuesday, April 20, 2004 6:39 AM
>>To: '[EMAIL PROTECTED]'
>>Subject: [ cf-dev ] Mach II
>>
>>Whats everyones take on the Mach II Framework?
>> 
>> 
>>
>>This e-mail is from Reed Exhibitions (Oriel House, 26 The Quadrant, 
>>Richmond, Surrey, TW9 1DL, United Kingdom), a division of Reed 
>>Business, Registered in England, Number 678540. It contains 
>information 
>>which is confidential and may also be privileged. It is for the 
>>exclusive use of the intended recipient(s). If you are not 
>the intended
>>recipient(s) please note that any form of distribution, 
>copying or use 
>>of this communication or the information in it is strictly prohibited 
>>and may be unlawful. If you have received this communication in error 
>>please return it to the sender or call our switchboard on +44 (0) 20 
>>89107910. The opinions expressed within this communication are not 
>>necessarily those expressed by Reed Exhibitions. Visit our website at 
>>http://www.reedexpo.com
>>
>>
>
>
>--
>These lists are syncronised with the CFDeveloper forum at 
>http://forum.cfdeveloper.co.uk/
>Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/
> 
>CFDeveloper Sponsors and contributors:-
>*Hosting and support provided by CFMXhosting.co.uk* :: 
>*ActivePDF provided by activepdf.com*
>      *Forums provided by fusetalk.com* :: *ProWorkFlow provided by
>proworkflow.com*
>           *Tutorials provided by helmguru.com* :: *Lists hosted by
>gradwell.com*
>
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>
>
>
>--
>These lists are syncronised with the CFDeveloper forum at 
>http://forum.cfdeveloper.co.uk/
>Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/
> 
>CFDeveloper Sponsors and contributors:-
>*Hosting and support provided by CFMXhosting.co.uk* :: 
>*ActivePDF provided by activepdf.com*
>      *Forums provided by fusetalk.com* :: *ProWorkFlow 
>provided by proworkflow.com*
>           *Tutorials provided by helmguru.com* :: *Lists 
>hosted by gradwell.com*
>
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>


-- 
These lists are syncronised with the CFDeveloper forum at 
http://forum.cfdeveloper.co.uk/
Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/
 
CFDeveloper Sponsors and contributors:-
*Hosting and support provided by CFMXhosting.co.uk* :: *ActivePDF provided by 
activepdf.com*
      *Forums provided by fusetalk.com* :: *ProWorkFlow provided by proworkflow.com*
           *Tutorials provided by helmguru.com* :: *Lists hosted by gradwell.com*

To unsubscribe, e-mail: [EMAIL PROTECTED]

Reply via email to