tightly coupled to the app" applies just as much to FB as to Mach-II (and
probably most other frameworks). The fact that it's not tightly coupled to
the app necessarily means that its not framework dependant, so you can't use
that as an argument for or against any given framework.
I've personally taken applications from FB4 -> Mach-II and from Mach-II ->
FB4 for various reasons. And I even have one that's actually a hybrid,
because part of it is much better suited to the event model of Mach-II, but
most of it is better off as FB (because it's simpler). In both cases the
backend didn't change a lick, which is at is should be.
Cheers,
barneyb
> -----Original Message-----
> From: Hugo Ahlenius [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 27, 2004 6:47 AM
> To: CF-Talk
> Subject: RE: Mach-II
>
> 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]
