> >well-defined private versus public APIs
> Again, doesn't apply to Fusebox
The common analogy is that a "fuse" is a private
method and a "fuseaction" is a public method.
I can understand the analogy, but that doesn't make a "fuse" a private
method and a "fuseaction" a public method. CF simply doesn't have the
ability to do this.
> >manageable distributed development
> What does Fusebox have that allows this...
Standardized documentation and division of labor. For each
"circuit" an architect can define the fuses using fusedocs,
send them to a developer in Australia, a designer in Zimbabwe,
and DBA in Malaysia and expect to have a completed application
the next morning.
Any methodology that has documentation should allow this.
> ... and what are other methodologies missing that make them
> unmanageable for distributed development?
What other methodologies? The only other methodologies I've
come across are variations of Fusebox and CFObjects. And CFObjects
isn't an option because it relies so heavily on unscalable custom
tags.
Almost every large scale CF application makes use of methodologies
invented for the project. This is why these projects have someone
designated as the application architect. This person is responsible for
creating architecture documents, application frameworks, methodologies,
and coding standards.
> >separation of presentation from logic from data-access
> Fusebox has a half-hearted attempt at this, but no true separation.
I somewhat agree with you there. The irony is that Cold Fusion was
designed to intermingle data access and presentation logic. Personally,
I've added a slight twist to my code (which is still perfectly valid
fusebox) that makes the seperation a little more of a reality.
> >excellent code re-use
> Excellent as compared to what?
Exactly. What's the alternative?
It seems you are looking for some published "silver bullet" that is
better than Fusebox. Again most large scale application architectures
are decided on after the project requirements have been decided.
Generally, these architectures are built from scratch for the project,
but rely on common well known techniques.
> >Add to that some excellent associated methodologies and tools like
> >wireframing, devnotes, test harnesses, and a large, thoughtful
> >community.
> These are specific to Fusebox.
Did you mean to say they're not specific to Fusebox? Most of them
aren't. But the Fusebox community is a friendly, outgoing bunch, and
we're used to working with each other and using these methodologies.
That's why the "it's the most popular" argument is so popular. :)
I meant they are not specific to Fusebox. Whoops :)
> >And a couple of useful Custom Tags.
> Custom tags don't scale. This isn't however specific to Fusebox tags.
I
> have yet to see a scalable CF application that made use of CFML custom
> tags.
Again, Fusebox doesn't rely on custom tags. The majority of those
"useful custom tags" Lee is referring to would have been written as
UDF's if we had that option at the time. Maybe this project can help
Fusebox finally free itself of its (apparent) dependence on custom
tags.
I discussed this issue off-list with Nat Papovich. I will forward the
thread to the list.
>I'm always interested in constructive criticism. If you can suggest a
better methodology or point out weaknesses in Fusebox I'd love to hear
your thoughts. Email me off list if you prefer.
There is no "silver bullet" methodology. This project should come up
with functional requirements and then decide on what is needed. Fusebox
may work, but more likely you will need something specific to the
problem at hand. It doesn't take long to come up with new architectures
and/or frameworks. Having something specific to the project is well
worth the effort.
-Matt
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
