ASP Coding Questions Discussion

[Michael D. Kersey]

Re: ASP Coding Questions Discussion

Lin Ma wrote:
<snipped>[color=blue]
> The con may be:
> 1. too many include command to make the system slow??[/color]
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=+%22compiled+to+bytecode%22+group:microsoft.public.inetserver.asp.general+author:mdkersey%40hal-pc.org&num=20&hl=en&lr=&safe=off&scoring=r&rnum=1&ic=1&selm=3A1AC55C.7CBEE4B%40hal-pc.org

[color=blue]
> My question is Am I Doing correct? Or there is a better solution?[/color]
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

[Bob Barrows]

Re: ASP Coding Questions Discussion

Guinness Mann wrote:[color=blue]
> In article <ePh$XJSYDHA.65 6@tk2msftngp13. phx.gbl>, reb_01501@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?"
>[/color]
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

[Jeff Cochran]

Re: ASP Coding Questions Discussion

>I dunno. I suppose I could put all the business logic into activeX[color=blue]
>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...[/color]

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.
[color=blue]
>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.[/color]

Nobody's talking about serving static pages, but rather about using
multiple pages over cramming all the code into one.
[color=blue]
>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.[/color]

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

[Ray at]

Re: ASP Coding Questions Discussion


"Guinness Mann" <GMann@dublin.c om> wrote in message[color=blue][color=green]
> > 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?"[/color][/color]

No, you're not.


[color=blue]
> "Aaron Bertrand [MVP]" <aaron@TRASHasp faq.com> wrote
> Why go to the trouble?[/color]

I guess for the same reason I wash my car instead of leaving it dirty,
although it runs the same regardless.[color=blue]
> 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[/color]
is[color=blue]
> 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...[/color]

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

[Michael D. Kersey]

Re: ASP Coding Questions Discussion

Guinness Mann wrote:
<snipped>[color=blue]
> 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...[/color]
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

[Guinness Mann]

Re: ASP Coding Questions Discussion

In article <uGiJ3RTYDHA.21 36@TK2MSFTNGP10 .phx.gbl>,
aaron@TRASHaspf aq.com says...[color=blue]
> 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...[/color]

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.

[color=blue]
> Personally, I'd rather see them separated out by functionality,
> purpose, etc.[/color]

Exactly!


Michael Kersey mentioned:[color=blue]
> the approach you use is sometimes called the "fusebox" approach[/color]

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

-- Rick

[Guinness Mann]

Re: ASP Coding Questions Discussion

In article <3f3a2c14.41985 0973@news.easyn ews.com>,
jcochran.nospam @naplesgov.com says...[color=blue]
> 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.[/color]

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.

[color=blue]
> 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..."[/color]

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

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

select case userInput
case "DisplayRos ter"
Call displayRoster(r osterId)
case "DisplayStudent Record"
Call displayStudentR ecord(studentId )
<blah, blah, woof, woof>
end select
End FileA

FileB
<!-- #include "rosterAccessRo utines.asp" -->
<blah, blah, woof, woof>
<!-- #include "stringUtilitie s.asp" -->

Sub displayRoster(r osterId)

Call getRosterDataFr omDatabase()
Call displayHtmlHead

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

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


Call displayHtmlTail
End Sub

End FileB

FileC
Sub displayStudentR ecord
<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]

Re: ASP Coding Questions Discussion

>> > Speaking of formatting, am I the only person in the world who puts some[color=blue][color=green][color=darkred]
>> > effort into formatting my ASP code so that it looks good in "view
>> > source?"[/color][/color]
>
>No, you're not.[/color]

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.
[color=blue][color=green]
>> "Aaron Bertrand [MVP]" <aaron@TRASHasp faq.com> wrote
>> Why go to the trouble?[/color]
>
>I guess for the same reason I wash my car instead of leaving it dirty,
>although it runs the same regardless.[/color]

You can wash a car...? :)
[color=blue]
>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.[/color]

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]

Re: ASP Coding Questions Discussion

Guinness Mann wrote:[color=blue]
>
> In article <uGiJ3RTYDHA.21 36@TK2MSFTNGP10 .phx.gbl>,
> aaron@TRASHaspf aq.com says...[color=green]
> > 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...[/color]
>
> 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.[/color]
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.
[color=blue]
> Michael Kersey mentioned:[color=green]
> > the approach you use is sometimes called the "fusebox" approach[/color]
>
> I'm intrigued. Tell me more. What are the characteristics of
> "fusebox" programming?[/color]

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]

Re: ASP Coding Questions Discussion

In article <3F3AC6AF.73968 D98@hal-pc.org>, mdkersey@hal-pc.org says...[color=blue]
> 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.[/color]

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.
[color=blue][color=green]
> > I'm intrigued. Tell me more. What are the characteristics of
> > "fusebox" programming?[/color]
>
> See http://aloha-webdesign.com/dloads/asp/aspfusebox.htm and
> http://www.fusebox.org/[/color]

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]

Re: ASP Coding Questions Discussion

In article <MPG.19a4100ae0 d9449e989694@ne ws.newsguy.com> ,
GMann@dublin.co m says...[color=blue]
> In article <uGiJ3RTYDHA.21 36@TK2MSFTNGP10 .phx.gbl>,
> aaron@TRASHaspf aq.com says...[color=green]
> > ...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...[/color][/color]
[color=blue]
> 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.[/color]

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