Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > ASP General > Design View for HTML or ASP Response.Write

Reply
Thread Tools

Design View for HTML or ASP Response.Write

 
 
Garry Stewart
Guest
Posts: n/a
 
      04-28-2004
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.
 
Reply With Quote
 
 
 
 
Aaron Bertrand - MVP
Guest
Posts: n/a
 
      04-28-2004
> 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.

--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/


 
Reply With Quote
 
 
 
 
Alan Howard
Guest
Posts: n/a
 
      04-28-2004
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


"Garry Stewart" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> 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.



 
Reply With Quote
 
Steven Burn
Guest
Posts: n/a
 
      04-28-2004
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> 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.



 
Reply With Quote
 
Garry Stewart
Guest
Posts: n/a
 
      04-29-2004
"Aaron Bertrand - MVP" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> > 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.


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.
 
Reply With Quote
 
Garry Stewart
Guest
Posts: n/a
 
      04-29-2004
"Alan Howard" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> 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.

> Alan
>
>
> "Garry Stewart" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) om...
> > 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.

 
Reply With Quote
 
Aaron Bertrand [MVP]
Guest
Posts: n/a
 
      04-29-2004
> 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>" ...

--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/


 
Reply With Quote
 
Michael D. Kersey
Guest
Posts: n/a
 
      04-29-2004
Garry Stewart wrote:
> 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
 
Reply With Quote
 
Alan Howard
Guest
Posts: n/a
 
      04-29-2004
"Aaron Bertrand [MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> 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


 
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
Can't view webforms in design view in visual Studio 2005 Robert Smith ASP .Net 2 04-27-2008 12:40 PM
Updates in Design view not moved to Source view andspal ASP .Net Web Controls 0 11-02-2006 08:13 AM
Web Controls switching from Design view to HTML view causing problems Ziyad Makki ASP .Net Web Controls 1 08-23-2004 07:13 PM
How to make a week view and day view calendar just like month view calendar in .NET ? Parthiv Joshi ASP .Net Web Controls 1 07-06-2004 03:15 PM
Wierd error when going to Design View from HTML view VB Programmer ASP .Net 1 07-10-2003 03:20 PM



Advertisments