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-12-2003
In article <(E-Mail Removed)>,
http://www.velocityreviews.com/forums/(E-Mail Removed) 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 <(E-Mail Removed)>,
(E-Mail Removed) 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


 
Reply With Quote
 
 
 
 
Bob Barrows
Guest
Posts: n/a
 
      08-12-2003
Guinness Mann wrote:
> In article <(E-Mail Removed)>,
> (E-Mail Removed) 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


 
Reply With Quote
 
 
 
 
Guinness Mann
Guest
Posts: n/a
 
      08-12-2003
In article <ePh$(E-Mail Removed)>, (E-Mail Removed)
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.)

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

 
Reply With Quote
 
Aaron Bertrand [MVP]
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?"


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


 
Reply With Quote
 
Aaron Bertrand [MVP]
Guest
Posts: n/a
 
      08-13-2003
> 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.


 
Reply With Quote
 
Michael D. Kersey
Guest
Posts: n/a
 
      08-13-2003
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
 
Reply With Quote
 
Bob Barrows
Guest
Posts: n/a
 
      08-13-2003
Guinness Mann wrote:
> In article <ePh$(E-Mail Removed)>, (E-Mail Removed)
> 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


 
Reply With Quote
 
Jeff Cochran
Guest
Posts: n/a
 
      08-13-2003
>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
 
Reply With Quote
 
Ray at
Guest
Posts: n/a
 
      08-13-2003

"Guinness Mann" <(E-Mail Removed)> 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]" <(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.
> 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


 
Reply With Quote
 
Michael D. Kersey
Guest
Posts: n/a
 
      08-13-2003
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
 
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