When you think ASP, think...
Recent Articles
All Articles
ASP.NET Articles
Related Web Technologies
User Tips!
Coding Tips

Sample Chapters
JavaScript Tutorials
MSDN Communities Hub
Official Docs
Stump the SQL Guru!
XML Info
Author an Article
Print this page.
Published: Wednesday, March 06, 2002

Print this Page - Comparing Classic ASP to ASP.NET

By Scott Mitchell

ASP.NET, Microsoft's latest Web-server programming technology, was released for public consumption in mid-January 2002. As developers begin to move to the technology, those who have a long background in classic ASP will likely feel a bit alienated, as the way things are done in an ASP.NET Web page can be confoundingly different than in a classic ASP page. Personally, I think these different ways of doing things are better, often requiring far fewer lines of (more readable) code to accomplish a task in ASP.NET as opposed to accomplishing the same task in ASP.

- continued -

Over the past few months I've been adding articles to ASPNET.4GuysFromRolla.com, articles that contain information about ASP.NET and are written using ASP.NET Web pages (as opposed to classic ASP pages, which the majority of articles on 4Guys are created with). A couple years ago I wrote a "Print this Page" script (written in VBScript for an ASP page, naturally) to allow a printer-friendly view of the articles here on 4Guys. (To try the printer-friendly view out, simply click on the Printer icon in the upper-right hand corner of any 4Guys article. Note that the printer-friendly view removes the links on the left and right, the table formatting, excessive graphics and banners, etc.)

In this article, I will briefly examine how the classic ASP printer-friendly script works, and how a new, ASP.NET version I created works. Hopefully examining these two approaches will show some fundamental differences between the way to accomplish tasks in ASP vs. ASP.NET.

The Classic ASP Print this Page Script
In August 2000 I wrote an article detailing how the "Print this Page" script works. Essentially, the script is its own ASP page (/ASPScripts/PrintPage.asp) and must be called with the URL to the page to be printed passed along in the querystring, like /ASPScripts/PrintPage.asp?REF=/webtech/030602-1.shtml. The script then reads the querystring information and uses the FileSystemObject to read the contents of the physical file that maps to the passed-in virtual filename.

Once the contents of the file have been read into a string, a printer-friendly header and footer is outputted and the contents of the string are placed inbetween. Realize that this approach has one serious side-effect that can be viewed as either a bug or a feature. Any in-line ASP code, such as <%=Date()%> or <% Response.Write str %>) is simply not displayed since the browser interprets it to be an unknown HTML tag. Since the user can do a View/Source on the printer-friendly page and see the ASP code of the page, this could be a potentially disastrous situation if the ASP page contains sensitive information, such as database connection strings, passwords, etc. However, since none of the articles here contain such information (all such information being safely tucked away in include files or separate demo ASP pages), it's no big deal.

Another downside of this side-effect is that if there are any in-line demos in the ASP page, they will not be displayed in the printer-friendly version. Simply put, the printer-friendly version takes the source code (script code and HTML) from a target ASP page and dumps the source wrapping it with a printer-friendly header and footer. Hence, if there is ASP code that needs to be executed within the page, it will not be executed in the printer-friendly page. As I mentioned earlier, this is not an issue with 4Guys articles, but it may be an issue for you and your Web site. (For more information on the "Print this Page" script be sure to read: How the "Print this Page" Script Works.)

An ASP.NET Implementation of the Print this Page Script
With the ASP.NET implementation I wanted to be able to have the ASP.NET contents of the script execute. The reasoning behind this stems from the fact that in a number of the articles found at ASPNET.4GuysFromRolla.com contain in-line demos; hence, not showing the output of these in-line demos in the printer-friendly version would make the printer-friendly versions less readable.

Before I continue onto how I surmounted this problem, let me first explain the general format of articles on ASPNET.4GuysFromRolla.com. Similar to the article layout on 4Guys, each article on ASPNET.4GuysFromRolla.com has a header and a footer surrounding the body of the article. On 4Guys, server-side includes are used to read in the header and footer files; on ASPNET.4GuysFromRolla.com, user controls are used. These user controls are nice because they can be treated like Web controls themselves - that is, user controls can have properties and methods, just like the standard Web controls (asp:textbox, asp:button, etc.).

On option I batted around was to have the user controls that emitted wrapper HTML around the article body support a property named ViewMode, which could be set to either Normal or Print. When ViewMode was set to Print, the user control would output printer-friendly HTML; when ViewMode was set to Normal it would emit the standard, graphics-intensive HTML. Then, in each article, I could have the Page_Load event handler check the querystring. If the querystring contained the key mode with the value print, the user control properties would be set to emit printer-friendly HTML.

While this is one valid approach, I vetoed it because I didn't want to have to add Page_Load event handlers to all of my existing article pages (and new ones). Rather, I wanted the user controls themselves to be smart enough to determine whether or not they needed to display printer-friendly or normal HTML. To accomplish this, I simply added two panel controls to my user controls, panelNormal and panelPrint, which, when used, look like:

<asp:panel id="panelNormal" runat="server">
  ... Place Normal HTML code here ...

<asp:panel id="panelPrint" runat="server">
  ... Place printer-friendly HTML code here ...

The panel control can be used to logically group HTML code and ASP.NET Web controls. Once we have this logical group, we can show or hide the group by simply setting the Visible property of the panel control. (For more information on using the panel control, be sure to read: ASP.NET Feature Saves Development Time.)

Next, in my user controls' Page_Load event handlers, I add a quick check to determine if the querystring contains a key named mode and a value named print. If it does, then I set panelNormal.Visible to False and panelPrint.Visible to True; otherwise, I set panelNormal.Visible to True and panelPrint.Visible to False. The code to do this check is fairly straightforward and can be seen below:

Sub Page_Load(sender as Object, e as EventArgs)
  If Request.QueryString("mode") = "print" then
    panelPrint.Visible = True
    panelNormal.Visible = False
    panelPrint.Visible = False
    panelNormal.Visible = True
  End If    
End Sub

With these few lines of code, I can toggle an article's printer-friendly view on by just appending ?mode=print to the querystring of the article. To allow the user to toggle this setting, on each article page on ASPNET.4GuysFromRolla.com you'll find a small printer icon in the upper-right hand corner of the article text. This IMG tag is surrounded by an HREF tag with the following code:

<A HREF="<%=Request.Path%>?mode=print">
	<IMG SRC="/images/printer.gif" ALT="Print this Page!" width="34"
	             height="34" align="right" border="1">

Note that I essentially take the path of the current page (as given by Request.Path) and then append to it ?mode=print. So if the user is visiting the URL: http://aspnet.4guysfromrolla.com/articles/020402-1.aspx, and they click the printer icon, they'll be taken to http://aspnet.4guysfromrolla.com/articles/020402-1.aspx?mode=print, which will cause the user controls to emit printer-friendly HTML. Curious how it looks? Try visiting the normal view of an article at ASPNET.4GuysFromRolla.com, and then check out its printer-friendly format.

Hopefully this article helped shed a little bit of light on how ASP.NET and classic ASP pages can differ in their design and makeup. Note that with classic ASP, we used a separate ASP page to handle the printer-friendly display. While I could have used a similar approach for the ASP.NET articles, I decided to make the user controls that normally emit the "standard" HTML a bit smarter by making them capable of emitting printer-friendly HTML as well, and knowing when to emit what. (Of course the classic ASP approach could have been written this way too, but when I wrote the original classic ASP "Printer This Page" script, it didn't occur to me to do it this way. However, the more one works with ASP.NET the more one thinks about encapsulating the complexity of various tasks within page-level abstractions (such as user controls) as opposed to going to an entirely new Web page.)

Happy Programming!

  • By Scott Mitchell

  • ASP.NET [1.x] [2.0] | ASPFAQs.com | Advertise | Feedback | Author an Article