Okay, I'll elaborate.
One nice benefit to having a fusebox architecture behind static content is
that you've got an instant roadmap of where all links are going to, insofar
that the links are within the app.
Because you can now one-stop-shop for all the in-app links in your app, it's
pretty easy to see what is doing what.
And if you should ever choose to start introducing dynamic content, you
already have the fusebox there, so it's a snap to integrate.
If you have anybody in your shop who knows Fusebox, they'll be able to pick
up the app and run with it, even though it might be almost entirely static
content.
Okay, there are a few good reasons why...
> -----Original Message-----
> From: Patrick McElhaney [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, April 12, 2001 10:53 AM
> To: Fusebox
> Subject: RE: Handling Static and Dynamic Pages
>
> > I'd fusebox everything. Fusebox serves as a means of linking
> > pages together,
> > and it works great even if your content is purely static. If you
> > had nothing
> > but .htm's for your display content, and had fuseactions hard-coded into
> > your HREFs and form submits, you'd still get a lot of benefits.
>
> I hate it when people say "a lot of benefits" and don't
> elaborate. What advantages does fusebox provide to static
> (portions of) web sites? And I'm not talking about things
> that could be accomplished by using an application to spit
> out static pages. BTW, pages that forms post to aren't
> static.
>
> Patrick
>
>
>
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
