> "compiles" your XML configuration file into straight inline CF code
> (one fuseaction at a time on demand, if I read Jeff Peters' book
> correctly!). That gives FB4 a performance edge over both Mach II and
> FB3.
That should be "one PUBLIC fuseaction at a time, on demand". Each public
fuseaction is compiled on the first call into an single .CFM file. In other
words, internal fuseactions (like model or view fuseactions in an MVC app)
will never be compiled, though their content will be included inline in the
compiled file of every public fuseaction that references them, directly or
indirectly. Yes, that means that an internal fuseaction will potentially be
compiled multiple times, with it's resulting CF code duplicated in multiple
public fuseaction files. However, that's an implementation detail of the
current setup, don't rely on that behaviour.
Plugins are textually included in the compiled file, they are not referenced
in-place with CFINCLUDE, so if you change a plugin, you must clear the
'parsed' directory to make the change effective. This is in contrast to
fuses, which are included via CFINCLUDE in the compiled file, so you can
change a fuse without requiring recompilation of the associated public
fuseactions.
A note on terminology:
The compilation process is refered to as "parsing" within FB4, so you have
the 'parser' core file, the 'parsed' directory, and 'parse files' which are
the result of converting the XML markup into CF code. Personally, I think
"compiling" is a vastly superior term in this instance, but it wasn't the
one selected.
Cheers,
barneyb
> -----Original Message-----
> From: Sean Corfield [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 02, 2004 11:34 AM
> To: CF-Talk
> Subject: Re: Fusebox 4 MVC
>
> > From: Sandy Clark <[EMAIL PROTECTED]>
> > Mach-ii - Implicit Invocation. Relies heavily on OOP and
> requires a good working knowledge of OOP
> > Fusebox - Pipes and Filter - Procedural in nature No OOP
> knowledge required.
>
> That's probably the best short answer I've seen to that question!
>
> Hal Helms generally says that if you're comfortable with OO and design
> patterns then Mach II may suit you better but otherwise Fusebox 4 will
> be a more comfortable fit. They both operate from an XML configuration
> file, they both promote separation of business logic and presentation
> code. They both support MVC (Mach II natively, FB4 optionally - see
> Brian's example). Which you pick (if you pick either) is going to
> depend entirely on what you feel comfortable working with.
>
> One neat - and unique - thing about FB4 is that it effectively
> "compiles" your XML configuration file into straight inline CF code
> (one fuseaction at a time on demand, if I read Jeff Peters' book
> correctly!). That gives FB4 a performance edge over both Mach II and
> FB3.
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
