Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > ASP General > ASP Coding Questions Discussion

Reply
Thread Tools

ASP Coding Questions Discussion

 
 
Guinness Mann
Guest
Posts: n/a
 
      08-13-2003
In article <(E-Mail Removed)>,
http://www.velocityreviews.com/forums/(E-Mail Removed) 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


 
Reply With Quote
 
 
 
 
Guinness Mann
Guest
Posts: n/a
 
      08-13-2003
In article <(E-Mail Removed)>,
(E-Mail Removed) 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
<!-- #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
 
Reply With Quote
 
 
 
 
Jeff Cochran
Guest
Posts: n/a
 
      08-13-2003
>> > 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]" <(E-Mail Removed)> 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
 
Reply With Quote
 
Michael D. Kersey
Guest
Posts: n/a
 
      08-13-2003
Guinness Mann wrote:
>
> In article <(E-Mail Removed)>,
> (E-Mail Removed) 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
 
Reply With Quote
 
Guinness Mann
Guest
Posts: n/a
 
      08-14-2003
In article <(E-Mail Removed)>, (E-Mail Removed) 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
 
Reply With Quote
 
Guinness Mann
Guest
Posts: n/a
 
      08-14-2003
In article <(E-Mail Removed)>,
(E-Mail Removed) says...
> In article <(E-Mail Removed)>,
> (E-Mail Removed) 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: ASP Classic > ASP.net discussion Bob Barrows ASP General 0 02-08-2012 12:33 AM
C++ Event Coding Questions AzizMandar C++ 4 11-09-2006 08:11 PM
general coding issues - coding style... calmar Python 11 02-21-2006 10:36 AM
MCSD Questions - A Discussion ampra MCSD 1 11-20-2004 06:01 AM
Re: Questions....questions....questions Patrick Michael A+ Certification 0 06-16-2004 04:53 PM



Advertisments