mmm...

Another thing that you aren't mentioning is code reuse -- the thing that
goes on between projects, or within parts of sub-projects. I think it
helps if you see every move you make as an investment in future projects
(and in the maintenance of the current project).

In fusebox you have a multitude of small reusable snippets (the fuses),
in addition to customtags and the occasional cfc.

In Mach-II you create a full backend of interacting CFC that are not
tightly coupled with the application can be easily re-used, even by
(with the exception of m2 listeners) non-mach-ii applications.

Using MVC (mach-ii, with fusebox or any framework) creates more
possibilities for this, of course.

--
Hugo Ahlenius

-------------------------------------------------------------
Hugo Ahlenius                  E-Mail: [EMAIL PROTECTED]
Project Officer                Phone:            +46 8 230460
UNEP GRID-Arendal              Fax:              +46 8 230441
Stockholm Office               Mobile:         +46 733 467111
                               WWW:       http://www.grida.no
-------------------------------------------------------------



| -----Original Message-----
| From: Alexander Sherwood [mailto:[EMAIL PROTECTED]
| Sent: Thursday, May 27, 2004 15:37
| To: CF-Talk
| Subject: RE: Mach-II
|
| At 06:48 AM 5/27/2004, you wrote:
| >> just plan it very well at first and document it very well.
| This might
| >> account for a large portion of the 9500h you plan to spent
| on it. But
| >> it is well worth it, even on relatively small projects.
| >
| >Tom stated it perfectly. It's all about planning. Well
| planned projects
| >are more likely to be successful regardless of framework or
| methodology.
|
| "No way Jose". Nearly a decade of programming with CF and
| other languages, I can tell you this is dead wrong. You can
| plan for 2 years on the best way to cross the Atlantic. If
| you planned to use a canoe, regardless of how "well" you
| planned, you're doomed. You're better of flying. The same
| goes for frameworks.
|
| Ever heard the _expression_ that "The road to hell is paved
| with good intentions."? The same applies for software
| development. You can plan till the cows come home, but unless
| you ** build and execute ** the project plan properly, then
| you are likely in incur steep software maintenance costs. No
| matter what, the bottom line is that CF needs to execute
| code, and unless that code is actually structured and written
| well, you're up the creek, regardless of how well or how much
| you planned.
|
| This is what is missed in the typical "framework" debates. It
| ** does** matter what framework you use. The notion that "any
| framework" will work is hogwash! My guess is this notion
| stems from the fact that CF developers typically work in
| small groups where they "pick and pull" at an application
| themselves over time and consider this "maintenance". A large
| development team (25-50 developers) must rely on a
| pre-determined contract on how software will be structured
| and executed to reduce dependence on each other. This is
| where the framework comes in.
|
| Have I used Mach-II? Once, on one project. Will I use it in
| the future? Without a doubt. Why? Because it provides an
| incredibly flexible foundation for building web applications
| that can be (as others have mentioned on this list)
| maintained and updated with minimal impact on the whole
| system. This saves money - typically not a concern for
| someone who's day is filled with deciding between
| CFSTOREDPROC and CFQUERY.
|
| Don't fall for the "some framework is better than none" argument.
|
| --
| Alex
|
|
|
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]

Reply via email to