ASP Coding Questions Discussion

Lin Ma

Hi,

I am wondering if I am doing right. Please advise.

I create a system with 8 major steps and each step can go different
direction. General speaking, a lot of if statements and functions inside.

Each page is over 1000 lines. In order for me to debug, I separate the lines
by function and create a template page.

Then I use <--# include... --> to link to this template page.

Also some of the code are shared with other page link query, table..., I
also create a temp page for this and include into other pages.

The pro is that:

1. if update, I just update one temp page and all the page will be updated.
2. easy to debug because it will make the page shorter. The one with include
page has only 140 lines and without the include page is over 1500 lines.

The con may be:

1. too many include command to make the system slow??

My question is Am I Doing correct? Or there is a better solution?

Thanks,

Lin Ma

Jul 19 '05 #1

Subscribe Post Reply

2375

Aaron Bertrand - MVP

What kind of application needs 1000 lines per page?

That seems ludicrously overboard, IMHO.

Each page is over 1000 lines. In order for me to debug, I separate the lines by function and create a template page.

Jul 19 '05 #2

Lin Ma

Thanks for the response. I have tables, headers, queries, JavaScript, I also
have if statements... Some pages also send email to certain group...

The system is like a documentation approval system, different level people
will take different action, sign their option and move to next level person.
The next person can reject, accept, on hold... A lot of functions.

My point is that Can I divide my code into server area by function. Each of
the area creates a separate file. Then use Include command to assembly this
files together?

Thanks for the response.

Lin

"Aaron Bertrand - MVP" <aa***@TRASHaspfaq.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

What kind of application needs 1000 lines per page?

That seems ludicrously overboard, IMHO.

Each page is over 1000 lines. In order for me to debug, I separate the

lines
by function and create a template page.

Jul 19 '05 #3

Martin CLAVREUIL

Off course you can do it but, always remember that a SSI (include statement)
is writen in the code is always included before any building of the code.
this mean that if you include a file in an if ... end if statement this file
will always be included.
This is a bit heavy for the server but can be really helpful for a debuging
purpose.
do not overuse it, that's all

Jul 19 '05 #4

Aaron Bertrand - MVP

> My point is that Can I divide my code into server area by function. Each
of

the area creates a separate file. Then use Include command to assembly this files together?

No, but you could use server.execute(). Includes are processed before ASP,
so any logic you use in ASP to determine which files to include will be too
late.

Jul 19 '05 #5

Lin Ma

Thanks.

Is there a better way to do to make page shorter?

Thanks a lot.

Lin

"Martin CLAVREUIL" <ma**************@wanadoo.fr> wrote in message
news:eQ**************@TK2MSFTNGP12.phx.gbl...

Off course you can do it but, always remember that a SSI (include statement) is writen in the code is always included before any building of the code.
this mean that if you include a file in an if ... end if statement this file will always be included.
This is a bit heavy for the server but can be really helpful for a debuging purpose.
do not overuse it, that's all

Jul 19 '05 #6

Jeff Cochran

On Mon, 11 Aug 2003 09:43:03 -0500, "Lin Ma" <a@a.com> wrote:

I create a system with 8 major steps and each step can go different
direction. General speaking, a lot of if statements and functions inside.

Each page is over 1000 lines. In order for me to debug, I separate the lines
by function and create a template page.
Creating functions is smart if the same code is being executed
multiple times. If executed once, just put it there.

1,000 lines is big. Big enough that you're likely causing a slowdown
somewhere that you don't need to. Modularize the options and put them
in separate code pages.
Then I use <--# include... --> to link to this template page.
In general, use includes to place the exact same block of code in
multiple pages. If it only runs once for the page it's on, don't use
an include.

But, you *might* use an include to separate code from HTML.
Also some of the code are shared with other page link query, table..., I
also create a temp page for this and include into other pages.
This is what includes are designed for, shared code or portions of
pages. I don't see the reason for a temp page, but that may be your
explanation or my ignorance that's confusing me.
1. if update, I just update one temp page and all the page will be updated.
Welcome to the reason for includes.
2. easy to debug because it will make the page shorter. The one with include
page has only 140 lines and without the include page is over 1500 lines.
Bleh! Break it into multiple pages. Just beacuse you can put
everything on one page doesn't mean you should.
The con may be:

1. too many include command to make the system slow??
Maybe, probably not noticably considering the system is processing all
those lines.
My question is Am I Doing correct? Or there is a better solution?

No matter how you do it, there's *always* a better solution. :)

I'd look at the programming logic. You mentioned eight major steps.
How many minor steps, and how many of those can be broken into
separate pages. Cheap example:

Big Pages:
===================
If User is Supervisor Then
Do code
Do more code
Do more code
End If

If User is Employee Then
Do code
Do more code
Do more code
End If
====================

Small Pages:
===================
If User is Supervisor Then
Goto Supervisor.asp
End If

If User is Employee Then
Goto Employee.asp
End If
====================

In the separate ASP pages, do the code for that IF statement. In this
pseudocode it saves four lines for the main page, and each individual
page is easier to debug.

Jeff

Jul 19 '05 #7

Guinness Mann

In article <ud**************@TK2MSFTNGP09.phx.gbl>, a@a.com says...

My point is that Can I divide my code into server area by function.
... Then use Include command to assembly this files together?

Sure you can, Lin Ma. Here's an example for you:

-----<begin file capitalizeWord.asp>-------
<%
Function capitalizeWord(w)
dim s, t, u, l
l = Len(w)

if (l = 0) Then
capitalizeWord = ""
exit Function
End If

s = Left(w, 1)
t = Right(w, l - 1)
u = Ucase(s)

capitalizeWord = u & t

End Function
%>
-----<end file capitalizeWord.asp>-------

and in file tests.asp:

------<begin file tests.asp>------
<%@ Language=VBScript %>
<%Option Explicit%>













-------<end file .asp>-------

Notice that you have to do the inclusions outside of the asp markers.
Also, there is no built-in protection against redundant including of
symbols, (no #ifdef in C++ speak) so you will have to come up with some
kind of scheme to protect yourself against that.

-- Rick

Jul 19 '05 #8

Aaron Bertrand - MVP

> I'm a little confused. I'm somewhat new to this ASP stuff, but I've

been developing software for over 20 years (way over, come to think of
it), and to my mind 1000 lines is not a big program.
For a "real" application, no. For a web page, that's massive. I've been
developing ASP applications for, what, 7 or 8 years now? IIS 3 beta 2,
whenever that was made available. And I've never seen, much less written,
an ASP page with 1000 lines.
Rather than have an unruly, unmanageable string of response.redirect-
related pages like the system it replaces, it has a central ASP page
that accepts the client-side input and generates the appropriate
response pages on the fly.
And you think this is more efficient?
So are you (Aaron, specifically) claiming that I should break that up
into a dozen individual pages that use the WEB equivalent of "goto"
(response.redirect) to switch between them?

When I build my sites, almost all of my content is stored in the database.
The information is not always retrieved directly from the database, e.g.
aspfaq.com uses a caching technology which only gets updated when the
articles actually change. The entire aspfaq.com site is about 120 lines of
code, and a good portion of that is style sheets / client-side javascript.

However I'm not claiming at all what you should or should not do. I think
if you have 1500-2000 lines of code, that's going to be a royal PITA to
manage, no matter how you decide to break it up (or not at all). I just
can't, for the life of me, imagine what you would need to do - for a set of
web pages - that would require that much code.

A

Jul 19 '05 #9

Jeff Cochran

>> >I create a system with 8 major steps and each step can go different

>direction. General speaking, a lot of if statements and functions inside.
>
>Each page is over 1000 lines. In order for me to debug, I separate the lines
>by function and create a template page.
1,000 lines is big. Big enough that you're likely causing a slowdown
somewhere that you don't need to. Modularize the options and put them
in separate code pages.

I'm a little confused. I'm somewhat new to this ASP stuff, but I've
been developing software for over 20 years (way over, come to think of
it), and to my mind 1000 lines is not a big program. In fact, it's
barely non-trivial.

VB apps routinely run many thousands of lines of code. But rarely
does the server need to process an entire VB application just to
display a logon screen. Plus, the nature of ASP and the web means you
don't need all the code for an application in one page.
Is it a matter of terminology? When Lin Ma says "pages" maybe she
doesn't mean what you guys mean when you say pages.
My take is a "page" means a single "file" processed and sent to the
browser.
In one of the subsystems of my application I have a main "page" that has
about 450 lines in it. About half of that is the main code (about half
of which is comments) and the other half is utility subroutines. There
is no display code in this file.
If Lin Ma has 1,000 lines and half are comments and another third are
blank, that's a different story. But in the ASP world, 1,000 lines of
code is pretty danged big.
In this main "page" I include fourteen directly related ASP files and
four data files. The ASP files collectively have about 700 lines in
them. In addition I include another nineteen general purpose ASP files
that do things like capitalize words, query the database, generate
dynamic "<select>" controls, etc. That adds another 500 lines of code,
or so.
That can also be dramtically squeezed from the sounds of it. Or at
least broken up.
Rather than have an unruly, unmanageable string of response.redirect-
related pages like the system it replaces, it has a central ASP page
that accepts the client-side input and generates the appropriate
response pages on the fly.
Unruly and unmanageable aren't the code's fault. But the solution is
rarely putting everything in one large file.
I don't see how it could be done in less than, well, 1500 - 2000 lines
of code.
I don't either. But I don't have the code... :)
So are you (Aaron, specifically) claiming that I should break that up
into a dozen individual pages that use the WEB equivalent of "goto"
(response.redirect) to switch between them?

No. But discreet points where user input is needed probably should be
in discreet pages. You have 500 lines of code that query databases,
capitalize words, create dynamic SELECT controls, all of which could
possibly be better handled elsewhere. (Well, for one thing, ASP.NET
might help with some of your controls...) If you don't need to query
a database at the same time you capitalize words, don't put the
functions in the same page. In fact, handle capitalization on the
input side instead of the output, you capitalize once instead of every
time.

There's no real "method" to handle any of this. And what works in one
case most certainly won't work in all. For example, I have pages
which could easily be optimized, but they rarely get run and the
performance increae would be minimal so why bother? My efforts are
better spent elsewhere.

Jeff

Jul 19 '05 #10

Guinness Mann

In article <u5**************@TK2MSFTNGP10.phx.gbl>,
aa***@TRASHaspfaq.com says...

When I build my sites, almost all of my content is stored in the database.
The information is not always retrieved directly from the database, e.g.
aspfaq.com uses a caching technology which only gets updated when the
articles actually change. The entire aspfaq.com site is about 120 lines of
code, and a good portion of that is style sheets / client-side javascript.
I just had a look at your homepage, and one of the lines is 6,566 chars
long. If I had 6,566 character-long-lines, I'd be able to complete my
websites in well under 120 lines, too. :-)
In article <3f****************@news.easynews.com>,
jc*************@naplesgov.com adds... VB apps routinely run many thousands of lines of code. But rarely
does the server need to process an entire VB application just to
display a logon screen. Plus, the nature of ASP and the web means you
don't need all the code for an application in one page.
Well, see, then it *is* a matter of terminology. I know that I don't
use that much code to display the screens that I present to the user,
and I suspect Lin Ma doesn't either. We're building large apps in ASP.
Maybe that's a bad idea.

I dunno. I suppose I could put all the business logic into activeX
objects and just do the rendering in ASP, but when I started this
project I didn't understand that. There would still be code to
maintain, although I admit I could make much better code in C++ than in
VBS...

I have a program. It has branches. Depending on which branch you take,
different code is included. There is code for students. Code for
instructors. Code for monitors. Code for administrators. I'm not just
serving up a bunch of static pages.

If you sum the lines of code I mentioned (about 1650) and divide that
figure by the number of files in the subsystem (34) you get less than 50
lines/file. On average. And they're never all included at the same
time. And about half (700) of those lines are re-used in other
subsystems.
Quoting Aaron again: Rick said:
Rather than have an unruly, unmanageable string of response.redirect-
related pages like the system it replaces, it has a central ASP page
that accepts the client-side input and generates the appropriate
response pages on the fly.
And you think this is more efficient?

Well...yeah. Efficient with respect to maintenance ... reliability ...
ease of change ... in other words efficient with respect to all the
things that make the difference between a software engineer and some kid
with a dbase compiler. :-)

My favorite part about it is that all the logic about what to display is
centralized where it can easily be reviewed or modified.

---

Remember, Lin Ma's question was whether or not it is possible to take a
large app and divide it up into modules of functionality and include
them where needed, instead of having everything in one huge file. The
answer is yes, most certainly.
-- Rick

Jul 19 '05 #11

Bob Barrows

Guinness Mann wrote:

In article <u5**************@TK2MSFTNGP10.phx.gbl>,
aa***@TRASHaspfaq.com says...
When I build my sites, almost all of my content is stored in the
database. The information is not always retrieved directly from the
database, e.g. aspfaq.com uses a caching technology which only gets
updated when the articles actually change. The entire aspfaq.com
site is about 120 lines of code, and a good portion of that is style
sheets / client-side javascript.

I just had a look at your homepage, and one of the lines is 6,566
chars long. If I had 6,566 character-long-lines, I'd be able to
complete my websites in well under 120 lines, too. :-)

:-)
Good one, but I think he's saying that the code used to generate those 6566
characters is only 120 lines long. Remember: he said most of the content is
stored in a database? I can well imagine that the code used to extract the
content from the db is not that long ...

Bob Barrows

Jul 19 '05 #12

Guinness Mann

In article <eP*************@tk2msftngp13.phx.gbl>, re*******@yahoo.com
says...

Guinness Mann wrote:
I just had a look at your homepage, and one of the lines is 6,566
chars long. If I had 6,566 character-long-lines, I'd be able to
complete my websites in well under 120 lines, too. :-)

:-)
Good one, but I think he's saying that the code used to generate those 6566
characters is only 120 lines long. Remember: he said most of the content is
stored in a database?

But then how is his website relevent to a discussion of large
applications? All he's doing is serving static pages. In concept it
could be done in four or five lines... In practice, of course it takes
a few more.

But that's nothing like having to generate all of the content except
formatting, dynamically.

Speaking of formatting, am I the only person in the world who puts some
effort into formatting my ASP code so that it looks good in "view
source?"

For instance, this is "view source" code: (I added the dots here on the
newsgroup to keep the indentation from collapsing. They're actually
rendered as tabs.)


<table style='border:none; width:100%'>
.....<tr>
.........<td align='left' class='greetings' style='width:25%;'>
.............Spanish Language
.........</td>
.........<td align='center' class='greetings'>
.............(If you're not John Adams, please 
.............<A HREF='/bmlc_asp/shell/getuser.asp'>click here</A>)
.........</td>
.........<td align='right' class='greetings' style='width:25%;'>
.............Class ID #0000000000spa</td>
.....</tr>
</table>


Another cool thing I found out is that ASP code inside HTML comments
will get executed on the server and written to the client, but NOT
DISPLAYED. But they'll show up in the "view source."

So, for instance, if you include:



in your source file, it will be rendered in view source like this:



but it won't be visible in the browser. It's a handy way to add
debugging variables without screwing up your presentation.

-- Rick

Jul 19 '05 #13

Aaron Bertrand [MVP]

> I just had a look at your homepage, and one of the lines is 6,566 chars

long. If I had 6,566 character-long-lines, I'd be able to complete my
websites in well under 120 lines, too. :-)
Uh, that's a stream of output from the database and inline functions, not a
hard-coded line in ASP.
Well...yeah. Efficient with respect to maintenance ... reliability ...
ease of change ... in other words efficient with respect to all the
things that make the difference between a software engineer and some kid
with a dbase compiler. :-)

Why, because there are fewer pages? 1,500 lines of code is 1,500 lines of
code. 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, the
maintenance aspect does not override the performance impact, IMHO. And I
still content that having one huge file does not necessarily make it easier
to manage. Personally, I'd rather see them separated out by functionality,
purpose, etc.

Jul 19 '05 #14

Aaron Bertrand [MVP]

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

effort into formatting my ASP code so that it looks good in "view
source?"

Why go to the trouble? I render most of my HTML output from Response.Write
calls. I have no use for the result of taking the effort to add all kinds
of VBTab and VBCrLf constants to the code... bloating it, for what? HTML is
not C++... if you have a problem with a table, it should be trivial to
solve. If it isn't, your HTML is too complex...

Jul 19 '05 #15

Michael D. Kersey

Lin Ma wrote:
<snipped>

The con may be:
1. too many include command to make the system slow?? It won't be slow except on the *first* page request after the server
starts. The reason is that the first time an ASP page is requested, it
is compiled to bytecode and saved in IIS memory. On successive calls,
the already-compiled bytecode is loaded. So only the first page request
will be slow. For more details see
http://groups.google.com/groups?q=+%...B%40hal-pc.org
My question is Am I Doing correct? Or there is a better solution?

While the structure you use is not common among ASP developers, it does
have some advantages and is perfectly fine, especially if it works for
you. There is no reason to abandon a successful approach.

FWIW the approach you use is sometimes called the "fusebox" approach. It
is most commonly used in the scripting language/engine Cold Fusion. But
it can be used in any language, as you can see.

Good Luck,
Michael D. Kersey

Jul 19 '05 #16

Bob Barrows

Guinness Mann wrote:

In article <eP*************@tk2msftngp13.phx.gbl>, re*******@yahoo.com
says...

Speaking of formatting, am I the only person in the world who puts
some effort into formatting my ASP code so that it looks good in "view
source?"

I agree with Aaron. I really don't care what it looks like when I view
source. I'm only viewing source for debugging purposes, which only happens
during the application development phase, at most once or twice (yeah, right
<grin>) - Any reformatting can be done by copying and pasting from notepad
into my editor. Once that phase is done, I really don't mind forcing the
hacker trying to reverse-engineer my page to add his own whitespace ...

Bob Barrows

Jul 19 '05 #17

Jeff Cochran

>I dunno. I suppose I could put all the business logic into activeX

objects and just do the rendering in ASP, but when I started this
project I didn't understand that. There would still be code to
maintain, although I admit I could make much better code in C++ than in
VBS...
That's an entirely different discussion, but it really does determine
a great portion of your coding design. There's always a debate about
where to place business logic, in a web app it's often on the web
server, but it could be front-end in an ActiveX control, or back end
in a database rule or stored procedure. Sometimes it makes sense to
choose one over another, sometimes it's the programmer's experience
that dictates the choice.
I have a program. It has branches. Depending on which branch you take,
different code is included. There is code for students. Code for
instructors. Code for monitors. Code for administrators. I'm not just
serving up a bunch of static pages.
Nobody's talking about serving static pages, but rather about using
multiple pages over cramming all the code into one.
If you sum the lines of code I mentioned (about 1650) and divide that
figure by the number of files in the subsystem (34) you get less than 50
lines/file. On average. And they're never all included at the same
time. And about half (700) of those lines are re-used in other
subsystems.

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. If you're using 30 files and including
only those pertinent to the page being executed, whether dynamically
or by manual design, that's normal good programming.

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..."

Jeff

Jul 19 '05 #18

Ray at

"Guinness Mann" <GM***@dublin.com> wrote in message

Speaking of formatting, am I the only person in the world who puts some
effort into formatting my ASP code so that it looks good in "view
source?"

No, you're not.
"Aaron Bertrand [MVP]" <aa***@TRASHaspfaq.com> wrote
Why go to the trouble?
I guess for the same reason I wash my car instead of leaving it dirty,
although it runs the same regardless. I render most of my HTML output from Response.Write
calls. I have no use for the result of taking the effort to add all kinds
of VBTab and VBCrLf constants to the code... bloating it, for what? HTML is not C++... if you have a problem with a table, it should be trivial to
solve. If it isn't, your HTML is too complex...

Aaron, you know that you can interlace your ASP code with HTML, right? ;P

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.

Ray at work

Jul 19 '05 #19

Michael D. Kersey

Guinness Mann wrote:
<snipped>

I dunno. I suppose I could put all the business logic into activeX
objects and just do the rendering in ASP, but when I started this
project I didn't understand that. There would still be code to
maintain, although I admit I could make much better code in C++ than in
VBS...

In all likelihood that would prove to be slower performance-wise. It
turns out that the additional time and memory required to load activeX
objects and marshall data to/from them causes them to be slower in most
instances.

The upshot is that while, with a component the server is busy handling a
CreateObject call and loading the component, a script would already be
executing and doing useful work. So script can actually make better use
of memory and CPU cycles, and usually outruns the component-based
approach:

"Rule of thumb: unless there are at least 100 lines of script and some
big loops in that script, it's probably not worth thinking about
translating that page into a component." Alex Homer, Dave Sussman,
Brian Francis, page 1042, "Active Server Pages 3.0"
(Wrox Press Ltd., 1999)

The book goes on to describe in more detail the circumstances under
which one should use components. Note the implication that any
component-based architecture requires that you do some very heavy
compute-bound work. This is not a common requirement.

See Microsoft's own proof that this really occurs in Figure 9 of
Microsoft's Nile.com benchmarks, which clearly shows how VBScript
outruns VB COM components especially under heavy load(many users):
http://msdn.microsoft.com/library/en...asp?frame=true

Good Luck,
Michael D. Kersey

Jul 19 '05 #20

Guinness Mann

In article <uG**************@TK2MSFTNGP10.phx.gbl>,
aa***@TRASHaspfaq.com says...

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

Jul 19 '05 #21

Guinness Mann

In article <3f****************@news.easynews.com>,
jc*************@naplesgov.com says...

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

<blah, blah, woof, woof>


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

Jul 19 '05 #22

Jeff Cochran

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

> effort into formatting my ASP code so that it looks good in "view
> source?"
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.
"Aaron Bertrand [MVP]" <aa***@TRASHaspfaq.com> wrote
Why go to the trouble?

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

Jul 19 '05 #23

Michael D. Kersey

Guinness Mann wrote:

In article <uG**************@TK2MSFTNGP10.phx.gbl>,
aa***@TRASHaspfaq.com says...
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.

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:
the approach you use is sometimes called the "fusebox" approach

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

Jul 19 '05 #24

Guinness Mann

In article <3F***************@hal-pc.org>, md******@hal-pc.org says...

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.

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/

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

Jul 19 '05 #25

Guinness Mann

In article <MP************************@news.newsguy.com>,
GM***@dublin.com says...

In article <uG**************@TK2MSFTNGP10.phx.gbl>,
aa***@TRASHaspfaq.com says...
...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...
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

Jul 19 '05 #26

Similar topics