[thelist] fusebox in ASP

David.Cantrell at Gunter.AF.mil David.Cantrell at Gunter.AF.mil
Mon Feb 3 10:23:02 CST 2003


>But it does use session and application variables.  You said this was bad
for performance, can you elaborate?  I'm still a >newbie to ASP, so I was
not aware of that.

Well, it's a combination of (a) the fact that you are marshalling data
between page requests, so it has to be stored on the server, where it
persists for 20 minutes after the user last makes a request, and (b)
personal preference. :)

I know that really helps, but really it's mostly just my opinion. It depends
on your situation. If you are designing a large-scale site or need low
response-time, then Session will chew your performance. If like me however
you are on a corporate intranet, then it really is less of an issue. I *do*
use Session variables, but very little, and really just to track boolean
flags; i.e. Session( "admin" ) is either true or doesn't exist, and is used
to provide login credentials.

>Can you give me some pointers in the right direction?  Maybe alert me to
pitfalls?  I'm in a crunch time wise, so any help >is mucho mucho
appreciated.

What I found is it is far better (IMHO) to break your site down into
modules, i.e. a Home Page module, an About Us module, etc. Each module goes
in a separate directory. Then each module has a default.asp file which acts
as a traffic cop for that module. This is the Fusebox-style part. All links
point only to the module's default.asp file and specify an action to take.
The default.asp then Server.Executes the file associated with that action.

What this does is help cut down the n-squared problem, where each n number
of pages can have n number of interfaces with each other. This way
establishes a level of indirection and information hiding at the module
level; each module is responsible for maintaining the relationship between
it's files and the associated actions to reach those files, and outside
pages only have to remember the action. That way, the module can change it's
internal structure without having to change every page that points to it.

It's fundamentally the same concept as writing functions and subroutines --
you hide the implementation and only expose the method signature. As long as
you don't change the way the method is called, it doesn't matter how it's
implemented.

So for example, you may have a site with a Home Page, About Us, Contact
Info, and a Products section. Then it's folder structure is layed out like
this:

	/<root>
	|-/home
	|-/about
	|-/contact
	|-/products

Each module (folder) has a default.asp file which acts as the traffic cop /
switchboard for the entire module. All calls go through this traffic cop.
Suppose the Products module has a couple of products, HairyWidget and
FuzzyWidget. Then we want to define what actions are available to allow the
user to view/interact with our products on the web. So we decide to allow
the user to "view" each widget, and maybe "download" the specification for
each.

So now we have a couple of actions: "view" and "download". Simple. All we do
is pass those in the URL as actions and also pass the widget we want to
manipulate as a parameter:

	http://www.mycompany.com/products/?action=view&product=HairyWidget

http://www.mycompany.com/products/?action=download&product=FuzzyWidget

Does this make sense? I know you can't see the implementation (like I said,
I haven't released the code yet) but hopefully you can see the concept. All
my code does is formalize this approach and establish a framework in which
you work and declare actions (in an XML file) and point those actions to the
appropriate files. The XML file can also handle headers, footer, leftnavs,
stylesheets, etc for the module or on a per-action basis. This leaves you to
focus on what is important -- the actual page content -- instead of
recreating and calling the headers, footers, etc from every script. The
framework then stitches it all together and builds the page on-the-fly as
the user requests it. I also have several helper VBScript classes for
transforming XML files via XSLT, making database calls, etc. I plan to
release all of that stuff sooner or later. Since there seems to be an
interest, maybe it will be sooner. :)

Appropriately enough I called it PageBuilder. I am a master of snazzy
marketing names, no? ;)

HTH,
-dave



More information about the thelist mailing list