> I love my signposts too,
> but I think putting all of the signposts in a database would make it
> even easier to find what I'm looking for. Imagine a plug-in for
> Studio that would allow me to browse my Fusebox app, rather than
> browsing the directory structure, etc.
It's the perceived problem with browsing the directory structure that I
don't get. Putting a database layer between me and something as fundamental
as the components of a fuseaction will only slow things down.
If I've got a fusebox/directory that is too cluttered, that's a sign that I
need to break things up into circuit applications and use the existing
database (the filesystem itself) more efficiently.
> I can see the CFParams being part of the database as well. Maybe
> CFModule, but see my other post. And of course CFLocation.
I dunno... I obviously don't see the value of the idea in general, but it
seems to me that if you were going to do that, you'd be better off pushing
all CFPARAMs, CFLOCATIONs, and even CFMODULEs into (for example) par_, url_,
and mod_ files and just including them.
> In a
> more generic way we can say that each fuseaction would have some
> initialization code and pointers to various subroutines. Personally,
> I *never* let any business logic creep into my index.cfm.
I try not to let logic into the various CFCASEs, but one of my objectives
with Fusebox is the modularization and reuse of code. If an extra CFIF in
index.cfm will let me repurpose a generic chunk of code, I'll add it.
> Surely there are patterns that you use over and over?
I don't personally consider the task of typing <CFSWITCH
expression="#attributes.fuseaction#">once in each index.cfm all that
onerous. [g]
--
Roger
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
