Design View for HTML or ASP Response.Write

[Garry Stewart]

Hello group,

I am wondering what the general public opinion is of using HTML tags
in an ASP script versus using Response.Write to display HTML code,
when you are developing Web Applications. (In particular database
apps)

It seems to me that using Response.Write gives you more control and
allows you to catch and display error messages. You can create a
library of functions that write out a standard header, standard footer
and client side scripts, and call them as simply as writePage( content
); from within each ASP script. Typically I buffer all of my content
to a String variable and dump it with a single Response.Write within
the writePage( content ) function. Can anyone point out any
pit-falls to doing this?

The down side seems to be that the HTML within the Response.Write gets
ugly, and it pretty much makes the Design View in Visual Interdev
useless.

Any positive suggestions or tips would be most welcome.

Thanks.

 

[Aaron Bertrand - MVP]

and it pretty much makes the Design View in Visual Interdev

useless.

I already thought that was useless anyway.

I use response.write most of the time, unless i have a large chunk of HTML
code that requires no logic. Those sections are still buried in
header/footer include files anyway, so it's not like ugliness or verbosity
becomes an issue.

 

[Alan Howard]

My opinion is that Design View was useless before using Response.Write .
Honestly though - never used it, always happier to see the code coming
together as I wrote it.

Seeing script tags interspersed with plain HTML is very common but something
I don't recommend. Generally I write all HTML out using Response.Write. Yes,
this does mean that you have to double-quote things like attribute values,
etc., but I feel that on the whole it makes for cleaner code that is easier
to read and maintain. It can be very difficult to get the feel of a page
where the page is half HTML and half VB Script with script tags embedded in
the middle of lines of HTML, hard-to-see conditional constructs, etc.
Keeping all code as VB Script also makes it easer to port the code to a VB
COM component later too - if you need to.

There may be a small performance hit using this approach for 'mostly' HTML
pages - I guess (never having looked seriously into it) that there is more
work to be done by the ASP interpreter than when you render straight HTML.
However, invoking the interpreter each time it comes across a little chunk
of VB Script would be more costly in those pages where the percentage of
script is higher. I forget the reference but I think you'll find words to
that effect in either the Wrox Beginning or Prof ASP books.

Also, be wary of concatenating all of your output into one big string. I
remember reading somewhere (I thought it was aspfaq.com - but can't find the
page) that VB concatenation is terribly inefficient.

Generally, I keep all of my HTML and VB Script inside a very small number of
script blocks on a page (normally, one), and use Response.Write to render
each line of HTML. For me that represents the best trade-off.

Alan

 

[Steven Burn]

I generally have most of my actual script's in include file's and don't put
the HTML inside response.write's, unless I have to (i.e. when doing a
for/next that includes tables) as I simply find it a pain in the backside.

--

Regards

Steven Burn
Ur I.T. Mate Group
www.it-mate.co.uk

Keeping it FREE!

Personal favourites

WebGrid - www.webgrid.co.uk
Freeware Arena - www.freewarearena.com
Freeware Home - www.freewarehome.com
Pricelessware - http://www.pricelessware.org
Practically Nerded - http://mvps.org/PracticallyNerded/
Bugs, Glitches n stuff - http://mvps.org/inetexplorer/Darnit.htm
Calendar of Updates - http://www.dozleng.com/updates/index.php?&act=calendar

 

[Garry Stewart]

I already thought that was useless anyway.

I use response.write most of the time, unless i have a large chunk of HTML
code that requires no logic. Those sections are still buried in
header/footer include files anyway, so it's not like ugliness or verbosity
becomes an issue.

Thanks for your comments Aaron. I am essentially doing the same
thing, whereby I have functions to insert the
header/footer/navigation, but inside the functions I use #include to
include raw HTML. This works well, but as I stated it makes using
the Design View impossible .. but nobody seems to use it anyway. For
static page content it may be a useful thing?

When using Response.Write for the bulk of the HTML, it does get ugly
to view. Perhaps this is because I buffer the results to a String
first. I do this because I do my own security authentication to
determine if clientA has rights to use the application they are
accessing, plus I need to trap any thrown exceptions from oracle, etc
and still present our corporate web look and feel to the user. This
has the side effect that each asp script can generate several response
pages.

Cheers.

 

[Garry Stewart]

My opinion is that Design View was useless before using Response.Write .
Honestly though - never used it, always happier to see the code coming
together as I wrote it.

Seeing script tags interspersed with plain HTML is very common but something
I don't recommend. Generally I write all HTML out using Response.Write. Yes,
this does mean that you have to double-quote things like attribute values,
etc., but I feel that on the whole it makes for cleaner code that is easier
to read and maintain. It can be very difficult to get the feel of a page
where the page is half HTML and half VB Script with script tags embedded in
the middle of lines of HTML, hard-to-see conditional constructs, etc.
Keeping all code as VB Script also makes it easer to port the code to a VB
COM component later too - if you need to.

First off, thanks for your feedback Alan )

I use JScript, because it is a superset of JavaScript, which I use for
client side code. I may have been lucky doing this because I heard
rhumor that VBScript will not be a supported .NET development
language, but that JScript will be. There is no need to debate this
though, ...

There may be a small performance hit using this approach for 'mostly' HTML
pages - I guess (never having looked seriously into it) that there is more
work to be done by the ASP interpreter than when you render straight HTML.
However, invoking the interpreter each time it comes across a little chunk
of VB Script would be more costly in those pages where the percentage of
script is higher. I forget the reference but I think you'll find words to
that effect in either the Wrox Beginning or Prof ASP books.

Having read a few postings on performance, I'm almost lead to believe
that using straight HTML means the interpreter does more work ... in
that it needs to translate the HTML to Response.WriteBlock() calls ...

Also, be wary of concatenating all of your output into one big string. I
remember reading somewhere (I thought it was aspfaq.com - but can't find the
page) that VB concatenation is terribly inefficient.

I use JScript, but I imagine that buffering to a string has its
inefficiencies still. I buffer the page output because my asp
scripts do their own authentication, and have the possibility of
catching exceptions, etc. In the event that something unexpected
arises, I need to be able to display user friendly messages to the
user within the layout of our corporate page look and feel.

Generally, I keep all of my HTML and VB Script inside a very small number of
script blocks on a page (normally, one), and use Response.Write to render
each line of HTML. For me that represents the best trade-off.

That makes sense, as the interpreter doesn't need to switch contexts
as often then.

Thanks again.

 

[Aaron Bertrand [MVP]]

Having read a few postings on performance, I'm almost lead to believe

that using straight HTML means the interpreter does more work ... in
that it needs to translate the HTML to Response.WriteBlock() calls ...

This may have been true in IIS3, IIS4, etc. No longer... the engine is much
smarter. If you have an .asp page that has no ASP code, for example, it
isn't even passed through the interpreter.

Anyway, these little things would have such minimal impact on performance,
I'd be surprised if you could measure the difference with a nano-second
stopwatch or with the best stress-testing tools out there.

If you want to improve performance, focus on data access, how you handle
large strings and objects, etc.

catching exceptions, etc. In the event that something unexpected
arises, I need to be able to display user friendly messages to the
user within the layout of our corporate page look and feel.

Have you considered using a custom 500 error handler? This would eliminate
your need to buffer the entire page in JScript. Which is going to be a much
larger performance killer than deciding whether to use <html> or
response.write "<html>" ...

 

[Michael D. Kersey]

I am wondering what the general public opinion is of using HTML tags
in an ASP script versus using Response.Write to display HTML code,
when you are developing Web Applications. (In particular database
apps)

The decision might also be guided by another consideration: whether your
team consists of
1. only developers (programmers) or
2. graphics design people and developers.

So if your shop has only developers and you never expect to have
graphics designers working on your ASP pages, then one could in
confidence use Response.Writes.

But graphics designers will want to see the page layout and modify it in
their tool of choice (e.g., DreamWeaver, FrontPage). In that case the
mixture HTML + ASP script provides a solution and more clearly delimits
the task responsibilities of each party.

IMO it is easiest to use mixed HTML + ASP since, among other things, you
never know to whom you might hand off (or sell) code. In the case of
selling code, the ability of the customer to easily customize the "look
& feel" of a site or application with any one of the variety of HTML
tools available is a powerful selling point.

As far as performance, the difference is insignificant, as has been
discussed many times in these newsgroups.

Good Luck,
Michael D. Kersey

 

[Alan Howard]

Anyway, these little things would have such minimal impact on performance,
I'd be surprised if you could measure the difference with a nano-second
stopwatch or with the best stress-testing tools out there.

I've never looked seriously at the performance issues and although the
arguments in here are interesting sometimes I agree that normally the code
itself will be more of a bottleneck (especially when you find one of your
developers iterating through nested recordsets) .

Alan