Thanks for the response.
I think you're right. If we add enough attributes, we ought to
be able to make this flexible enough to work. It doesn't matter
if we have thirty attributes, because they can all be given
default values.
If the basic framework of fusebox is pretty rigid, this should
be a no-brainer. If there are idiosyncrasies that can't be
easily contained in an attribute, this could go one of three
different ways:
A) We abandon the idea of encapsulating fusebox in a tag/class.
B) We tighten the fusebox model to eliminate these idiosynchosies.
C) We come up with a creative way to extend the CF_Fusebox interface.
Patrick
> -----Original Message-----
> From: David Huyck [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 06, 2001 4:06 PM
> To: Fusebox
> Subject: Re: CF_Fusebox
>
>
> Hmm... I kinda like that! This seems like something you could translate
> pretty easily to a PHP-fusebox class, too:
>
> $Fusebox= new Fusebox;
> $Fusebox->open();
> switch($fuseaction) {
> case "list":
> include("qry_getList.php");
> include("dsp_viewList.php");
> break;
> [etc...]
> }
> $Fusebox->close();
>
> Issues I forsee are thinkgs like portability-- making sure the location of
> the app_globals, etc. is one of the attributes of the tag/class, so if you
> have to move an app to a deeper location in the larger app, you can still
> tell the fusebox where it is in relation to the app_globals, app_layout,
> etc.
>
> I'll see what I can come up with in PHP, and you keep us posted on your CF
> version...
>
> David Huyck
> [EMAIL PROTECTED]
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
