ASP Coding Questions Discussion

[Guinness Mann]

I guess if you're maintaining your code more often than
running it... if you're having the ASP engine process
1,500 lines of code for every single page in your
application, even the ones that only use 20 lines...

Gosh, I hope that's not what the OP was suggesting. It's certainly not
what I'm proposing.

The way I design my subsytems is to have a central page to which all of
the forms in the subsystem post. This page doesn't do any display work
at all, but functions sort of like a Windows message loop. It looks at
the current state (it took me a while to figure out how to persist state
in this stateless world!) and the user input and decides what page to
serve or what process to invoke. The pages that get served have their
own processing portions and display portions.

That way, for any given trip through the loop, only a small portion of
the code is processed. With respect to code size, I don't see the
difference between that and having the decision logic spread across a
bunch of inter-related pages.

The big difference is that when it comes time to modify the logic it is
all contained in a central place where it can be easily grokked without
having to follow it around a bunch of pages that have processing logic
mixed up with the presentation layer.

Personally, I'd rather see them separated out by functionality,
purpose, etc.

Exactly!


Michael Kersey mentioned:

the approach you use is sometimes called the "fusebox" approach

I'm intrigued. Tell me more. What are the characteristics of
"fusebox" programming?

-- Rick

 

[Guinness Mann]

That's different. On a dynamic include you can do this. The way Lin
Ma had described the setup, all lines were included, and by that
virtue processed, they were just broken into separate files for ease
of debugging and maintenance.

Oh that would be horrible. I actually saw this done once back in the
80s. A famous author of BBS software had been chastised for his multi-
thousand line source files. He finally gave in and asked how long his
source files should be. Somebody told him that it was variable, but
about a hundred lines would be a good rule of thumb. He took a "split"
utility and broke up each file into 100-line portions. The poor guy
just didn't get it.

The real problem with ASP is the difficulty of doing dynamic includes.
It's easy to do "If this then do this" but not as easy to do "If this
then do this, but if not, don't even put the code to do it in..."

I do it like this (very simplified psuedocode example):

FileA
<blah, blah, woof, woof>
userInput = Request.Form("event")

select case userInput
case "DisplayRoster"
Call displayRoster(rosterId)
case "DisplayStudentRecord"
Call displayStudentRecord(studentId)
<blah, blah, woof, woof>
end select
End FileA

FileB
<!-- #include "rosterAccessRoutines.asp" -->
<blah, blah, woof, woof>
<!-- #include "stringUtilities.asp" -->

Sub displayRoster(rosterId)

Call getRosterDataFromDatabase()
Call displayHtmlHead

<table>
<blah, blah, woof, woof>
</table>

<form name=form1 id=form1 action=FileA.asp>
<blah, blah, woof, woof>
<input type=hidden name=event value="">
<input type=button id=button1 value="Display Student Record"
onclick='form1.event.value="DisplayStudentRecord";
form1.submit()'>
</form>


Call displayHtmlTail
End Sub

End FileB

FileC
Sub displayStudentRecord
<blah, blah, woof, woof>
End Sub
End FileC

Etc.

Notice that the "action" in FileB refers back to FileA which will
process the event and decide what to do next. If the user clicks the
"Display Student Record" button then the FileB routines will be unloaded
and the FileC (or whatever) routines will be loaded....


--Rick

 

[Jeff Cochran]

Speaking of formatting, am I the only person in the world who puts some

No, you're not.

I'm probably 60/40 on this. I'm getting better, but it really depends
on the page and whether I'm doing my own or someone else's code.

I guess for the same reason I wash my car instead of leaving it dirty,
although it runs the same regardless.

You can wash a car...?

I don't disagree with you about the HTML, but I personally "code" all my
HTML with strict tabbing, because when I do miss a tag somewhere or
something, it'll jump right out on me. I'm not going to spend an hour
looking for some stupid <tr> somewhere instead of doing what I really should
be doing. That is why I "code" my HTML they I do.

I'm better in this regard. Many of my pages are entirely ASP with
Response.Write statements to write out the HTML. But the majority
have the significant HTML portions in HTML, mostly for the same
reason, since my editors highlight the missing tags.

Jeff

 

[Michael D. Kersey]

Gosh, I hope that's not what the OP was suggesting. It's certainly not
what I'm proposing.

The way I design my subsytems is to have a central page to which all of
the forms in the subsystem post. This page doesn't do any display work
at all, but functions sort of like a Windows message loop. It looks at
the current state (it took me a while to figure out how to persist state
in this stateless world!) and the user input and decides what page to
serve or what process to invoke. The pages that get served have their
own processing portions and display portions.

That way, for any given trip through the loop, only a small portion of
the code is processed. With respect to code size, I don't see the
difference between that and having the decision logic spread across a
bunch of inter-related pages.

The big difference is that when it comes time to modify the logic it is
all contained in a central place where it can be easily grokked without
having to follow it around a bunch of pages that have processing logic
mixed up with the presentation layer.

Sounds like an ASP implementation of OOP's MVC (Model-View-Controller)
pattern ( http://ootips.org/mvc-pattern.html ). The logic is in the
Model, the View presents data, the Controller accepts user input and
sends it to the Model.

Michael Kersey mentioned:

I'm intrigued. Tell me more. What are the characteristics of
"fusebox" programming?

See http://aloha-webdesign.com/dloads/asp/aspfusebox.htm and
http://www.fusebox.org/
As I stated earlier, the FuseBox architecture originated in Cold Fusion,
which has a dynamic INCLUDE facility, so application of FuseBox to ASP
is not 1-to-1. I'm no particular proponent of the FuseBox architecture,
but simply am aware of it's existence (I made the mistake of registering
on a FuseBox e-mail list years ago and still get spam from various
FuseBox folks).

Good Luck,
Michael D. Kersey

 

[Guinness Mann]

Sounds like an ASP implementation of OOP's MVC (Model-View-Controller)
pattern ( http://ootips.org/mvc-pattern.html ). The logic is in the
Model, the View presents data, the Controller accepts user input and
sends it to the Model.

I *wish* it were that sophisticated. It's really just a message loop,
processing events with respect to states. Any real-time embedded
programmer or Windows OS mechanic would recoginize it immediately.

See http://aloha-webdesign.com/dloads/asp/aspfusebox.htm and
http://www.fusebox.org/

Oh, I get it. It's a play on the word "fusion," as in "Cold Fusion." I
had this picture in my mind of fuses blowing and sparks flying.

Thanks,

-- Rick

 

[Guinness Mann]

Rick said:
The way I design my subsytems is to have a central page to which all of
the forms in the subsystem post. This page doesn't do any display work
at all, but functions sort of like a Windows message loop. It looks at
the current state (it took me a while to figure out how to persist state
in this stateless world!) and the user input and decides what page to
serve or what process to invoke. The pages that get served have their
own processing portions and display portions.

That way, for any given trip through the loop, only a small portion of
the code is processed. With respect to code size, I don't see the
difference between that and having the decision logic spread across a
bunch of inter-related pages.

Hmm...I thought about this for a while last night and ... I hate to
admit it ... but I could be wrong.

It depends on your definition of "processed." It only has to *execute*
a small portion of the code, but because VBS has no concept of "header"
files like C, C++, or Java, it has to load all of the code in the whole
subsystem in order to resolve references. So when it hits an include
file, it not only has to read the include file, but all the files it
includes and all of the files they include, all the way to the leaves of
the tree.

In C++, on the other hand, all that would have to be read would be the
header files for the included routines in order to get the signatures
and other definitions.

Luckily, for me, my application runs on a LAN and never has more than 50
users at one time. The maintainability of my approach makes it
appropriate even though it is memory/processor intensive.

If I was designing a high-profile, high-volume site like Aaron's,
though, I'd probably have to consider a different approach.

There. I said it.

-- Rick