Published: Wednesday, March 06, 2002
Print this Page - Comparing Classic ASP to ASP.NET
By Scott Mitchell
Introduction
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.
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>
<asp:panel id="panelPrint" runat="server">
... Place printer-friendly HTML code here ...
</asp:panel>
|
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
Else
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">
</A>
|
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.
Summary
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
