ASP Coding Questions Discussion

L

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
 
A

Aaron Bertrand - MVP

What kind of application needs 1000 lines per page?

That seems ludicrously overboard, IMHO.
 
L

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
 
M

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
 
A

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

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.

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
 
G

Guinness Mann

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%>

<!--#include virtual="bmlc_asp/includes/adovbs.inc"-->

<!--#include virtual="bmlc_asp/includes/capitalizeWord.asp"-->
<!--#include virtual="bmlc_asp/includes/ConnectionString.asp"-->

<!--#include virtual="bmlc_asp/includes/debugScreen.asp"-->
<!--#include virtual="bmlc_asp/includes/makeOption.asp"-->
<!--#include virtual="bmlc_asp/includes/queryDatabase.asp"-->

<!--#include virtual="bmlc_asp/TestCreation/TestClass.asp"-->
<!--#include virtual="bmlc_asp/TestCreation/TestQuestionClass.asp"-->

-------<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
 
A

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
 
J

Jeff Cochran

I create a system with 8 major steps and each step can go different
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
 
G

Guinness Mann

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. :)


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:
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
 
B

Bob Barrows

Guinness said:
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
 
G

Guinness Mann

:)
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.)

<!-- Begin Greetings.Asp -->
<table style='border:none; width:100%'>
.....<tr>
.........<td align='left' class='greetings' style='width:25%;'>
.............Spanish&nbsp;Language
.........</td>
.........<td align='center' class='greetings'>
.............(If you're not&nbsp;John&nbsp;Adams, please&nbsp;
.............<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>
<!--End Greetings.asp-->

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:

<!-- Called from <%=Request.ServerVariables("SCRIPT_NAME")%> -->

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

<!-- Called from /bmlc_asp/tests/testpresenter.asp -->

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

-- Rick
 
A

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

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

Michael D. Kersey

Lin Ma wrote:
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=+...&rnum=1&ic=1&[email protected]
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
 
B

Bob Barrows

Guinness said:
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
 
J

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
 
R

Ray at

No, you're not.


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
 
M

Michael D. Kersey

Guinness Mann wrote:
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-us/dnnile/html/docu2kbench.asp?frame=true

Good Luck,
Michael D. Kersey
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top