Microsoft Corporation
November 12, 1999
Introduction
Did you know that you can safely edit Active Server Pages (ASP) files in Microsoft FrontPage 2000? New and improved handling of ASP in FrontPage 2000, combined with a few basic rules for implementing ASP, allows developers to feel comfortable letting end users edit pages that include ASP code. This article describes how FrontPage determines if code can be interpreted, how it handles code in various situations, and provides tips for writing code that is "safe" for your users to edit using the WYSIWYG (what you see is what you get) features of FrontPage.
Note For security information about working with Web sites and Web servers, see FrontPage Security Best Practices.
ASP and HTML
In learning how FrontPage handles ASP, it's important to understand the relationship between ASP and HTML. ASP is a technology for interspersing programming code within an HTML page. A given ASP page may be almost all HTML tags with a few lines of ASP code interspersed with HTML in well-defined ways, for example, in order to generate some text:
<H1>Welcome <% session.username %>!</H1>
or to generate an attribute value:
<BODY bgcolor="<% session.preferences.bgcolor %>">
Alternatively, an ASP page may completely consist of program code used to generate HTML. In this extreme case, the page is not a structured HTML page until it is dynamically executed by the ASP interpreter; the FrontPage Normal View adds no value here since there is no HTML for it to display.
A given ASP page can fall in the spectrum between these two extremes.
Using FrontPage to Edit ASP Pages
When an ASP page consists primarily of HTML, or contains large blocks of HTML, the FrontPage Normal View can be used to edit that HTML in the same way it can be used to edit any other HTML page. When an ASP page consists primarily of program code, the page developer would likely need code editing features (such as syntax checking and coloring and statement completion) provided by rich program editors like Microsoft Script Editor or Visual Interdev.
When FrontPage loads an ASP page, it takes care to preserve the ASP code but it does not (and, logically, cannot) actually interpret the ASP code to determine what HTML it would generate. When FrontPage loads any HTML page or ASP page, it needs to process the HTML into an in-memory data structure that represents the page. If the HTML tags are hidden within blocks of ASP, FrontPage cannot see the HTML tags and therefore cannot properly load the HTML.
How FrontPage Opens and Displays HTML files
When FrontPage opens a file, it reads the HTML tags in order to build an internal data structure representing the page. This process is called parsing. During the parsing process, FrontPage will automatically handle common errors or omissions in the page (for example, multiple <BODY> tags or omitted end tags). This automatic error handling is designed to match the process that the browsers perform when reading the page. Some of this error handling is part of the HTML standard (for example, you may omit the </TR> tag before </TABLE>) and some is performed simply to be more robust in handling common errors that appear in hand-written HTML (such as multiple <BODY> tags). In all cases, FrontPage's behavior is designed to match the browser's behavior so that pages that can be loaded by the browser can also be properly loaded, displayed and edited by FrontPage.
Error handling during the parsing process is important when discussing ASP pages because some common ASP programming idioms can look like parsing errors. The presence of these errors in an ASP page may indicate problems in loading an ASP page into FrontPage's Normal View. For example, if an ASP writer wanted to control the background and text color on a page, she could use either of the following techniques:
<% if (black_on_white) %>
<body bgcolor=white text=black>
<% else %>
<body bgcolor=black text=white>
<% endif %>
When FrontPage sees this page, the ASP blocks are not interpreted, so this simply looks like the common error of multiple body tags.
Alternatively, this same effect could have been achieved by this ASP:
<body bgcolor="<% if (black_on_white)%> white <% else %> black <%end if%>"
text="<% if (black_on_white)%> black <% else %> white <% end if%>">
In this case, there is a single body tag that can be parsed without any errors by FrontPage.
Sample page in Normal View
.gif)
Sample page in HTML View
.gif)
How FrontPage Opens and Displays ASP files
When FrontPage opens a file that includes ASP code, it only parses the HTML and preserves the ASP code inline-much as it preserves comments. If FrontPage parses a file that contains ASP code and is able to correctly interpret all of the HTML, it opens the file in Normal View. The preview in Normal View does not display the portions of the page that are generated using ASP code.
If necessary parts of the page are generated by processing the ASP code, the remaining HTML may appear invalid to FrontPage. In that case, the page is opened in HTML View. For example, if a table tag is generated by ASP code, but the <TR> and <TD> tags are not, then the <TR> and <TD> tags will appear to be errors.
Things that FrontPage detects as errors include the following: partial tags, repeated tags, body tags inside HTML, inferred non-optional tags, discarded tags, unmatched end tags, and non-optional end tags inferred.
By opening the page in HTML View, FrontPage gives you the opportunity to repair anomalies that might prevent the page from being safely edited in Normal View. By opening an ASP file in HTML View, FrontPage avoids introducing (perhaps erroneous) changes into the ASP code that would be necessary to make to display it in Normal View.
Important If a page opens initially in HTML View, do not switch to Normal View until you have corrected any anomalies. Because FrontPage will repair any errors in HTML code when you switch to Normal View, it is possible that switching to Normal View before repairing your code will introduce errors into your code. Here is the dialog box users will see when attempting to switch from HTML View to Normal (WYSIWYG) View on ASP pages containing anomalies.
.gif)
If you create ASP code that cannot be displayed in Normal View, you should understand that people will have to edit the page in HTML View. Depending on the level of experience the users have with creating and editing HTML, you may want to rewrite your ASP code so that the pages can be displayed in Normal View. The rest of this paper illustrates how you can write ASP code that can be edited in Normal View.
Example of ASP code that opens in Normal View
Example of ASP code that opens in Normal View
The following code does not include any tags that FrontPage would interpret as anomalies. Parsing this file and ignoring the ASP code keeps all of the HTML intact. (Note, the ASP code begins with the <% tag and ends with the %> tag.)
<html>
<body>
<% dim sHeading
sHeading="This is a test" %>
<h1>Page -- <%response.write sHeading%></h1>
Chapter one
<table width=100%>
<tr><td><%=rsTest("field1")%></td></tr>
<tr><td><%=rsTest("field2")%></td></tr>
<tr><td><%=rsTest("field3")%></td></tr>
</table>
<%response.write "<UL>"%>
<%response.write "<LI>test1"%>
<%response.write "</UL>%>
Contents of Chapter one
</body>
</html>
This code displays information from a database in a table. If you open this code in FrontPage, it will open the file in Normal View as shown.
.jpg)
Example of ASP code that opens in HTML View
In contrast, a file that includes ASP code that is necessary to complete an HTML tag will cause the file to open in HTML View.
In this example, the ASP code generates a <td> tag, which FrontPage will interpret as an abnormality. If you open this code in FrontPage, it will open the file in HTML View as shown here.
<html>
<body>
<% dim sHeading
sHeading="This is a test" %>
<h1>Page -- <%response.write sHeading & "</h1>" %>
Chapter one
<table width=100%>
<tr> <% response.write "<td>" & rsTest("field1") %></td></tr>
<tr><td><%=rsTest("field2")%></td></tr>
<tr><td><%=rsTest("field3")%></td></tr>
</table>
Contents of Chapter one
</body>
</html>.jpg)
Code Samples
This section provides code samples and discusses what FrontPage interprets as anomalies and why it will open an ASP page in HTML View or Normal View.
Partial Tags
FrontPage searches for partial tags in two ways: by looking for the < symbol in an attribute name and, by looking for the > symbol in normal text. Although in HTML it is legal to use the > symbol in normal text, FrontPage identifies it as suspicious since both the < and > symbols are generally encoded using "<" and ">" respectively.
For example, if you want to generate a table's width dynamically, the example on the left opens in HTML View because part of the <TABLE> tag is not in ASP. The example on the right opens in Normal View because the ASP is entirely within the tag's attribute.
| Opens in HTML View | Opens in Normal View |
<%response.write "<table width="
& sTableWidth %> >
<tr><td>test</td></tr>
</table>
| <table width="<%response.write
sTableWidth %>">
<tr><td>test</td></tr>
</table>
|
Tags only allowed once
The HTML, HEAD, BODY, and TITLE tags are only allowed to be used once in an HTML page. For example, if you want to set the body background color conditionally, the sample code on the left would open in HTML View because it contains 2 <BODY> tags. The sample on the right would open in Normal View because it contains only one <BODY> tag.
| Opens in HTML View | Opens in Normal View |
<% if error=1 %>
<body bgcolor="red">
<%else%>
<body bgcolor="blue">
<%end if%>
</body>
| <% if error=1 %>
sBgColor="red"
else
sBgColor="blue"
end if
%>
<body bgcolor= "<%response.write
sBgColor%>">
</body> |
A more subtle example of tags occurring more than once is when FrontPage encounters a tag that requires a <HEAD> or <BODY> tag surrounding it, and therefore infers a <HEAD> or <BODY> tag, and then later encounters an explicit <HEAD> or <BODY> tag.
BODY in HTML with FRAMESET
If a BODY tag occurs in FRAMESET page, outside of the <NOFRAMES> tag, FrontPage will consider this an anomaly. Ordinarily, FrontPage would repair this anomaly by moving the contents of the BODY into a NOFRAMES tag inside the FRAMESET. In the first sample, the page opens in HTML View because the BODY tag is in the ASP code. In the sample that opens in Normal View, the ASP code writes the BODY tag. FrontPage does not record this as an anomaly, and opens the page in Normal View.
| Opens in HTML View | Opens in Normal View |
<% if noframes browser%>
<body bgcolor="red">
<%else%>
<frameset rows="280,*">
<frame name="test"
src="test11.asp">
<frame name="test2"
src="test12.asp">
</frameset>
<%end if%>
| <% if noframes browser
response.write "<body
bgcolor=""red"">"
else %>
<frameset rows="280,*">
<frame name="test" src="test11.asp">
<frame name="test2" src="test12.asp">
</frameset>
<%end if%>
|
Inferred non-optional tag
Although in HTML the start tag of some tags, such as HTML, HEAD, BODY, TBODY, and NOFRAMES, can be omitted, FrontPage identifies these omissions as anomalies. If FrontPage encounters a missing start tag-such as a list item outside a list or a table cell outside a table-it would normally insert the missing tags. However, in an ASP file, it is possible that a tag such as <UL> or <TABLE is actually being written by an ASP script, so FrontPage will interpret this as an anomaly and open the page in HTML View.
In the sample on the left, FrontPage does not see the <TABLE> and </TABLE> tags, and opens the page in HTML View. In the sample on the right, explicit <TABLE> and </TABLE> tags allow FrontPage to open the page in Normal View.
| Opens in HTML View | Opens in Normal View |
<%response.write "<TABLE>"%>
<tr><td>test1</td></tr>
<tr><td>test2</td></tr>
<%response.write "</TABLE>"%>
| <%response.write "Hello"%>
<TABLE>
<tr><td>test1</td></tr>
<tr><td>test2</td></tr>
</TABLE>
|
Unmatched open or close tag
If FrontPage sees a close tag without a corresponding open tag, it will discard it, and register an anomaly. If FrontPage sees an open tag, which requires a close tag, but that close tag is missing, that too will be considered an anomaly. In the sample on the left that opens in HTML View, the <SELECT> tag is within the ASP code, and FrontPage only sees the </SELECT> tag. To fix this problem, make sure that both the open and the close tags are outside of the ASP code, and the page will open in Normal View.
| Opens in HTML View | Opens in Normal View |
<%response.write "<SELECT>"
do while not rsTest.eof
response.write "<option>" &
rsTest("LastName")
rsTest.movenext
loop
%>
</SELECT>
| <SELECT>
<% do while not rsTest.eof
response.write "<option>" &
rsTest("LastName")
rsTest.movenext
loop
%>
</SELECT>
|
Tips for writing ASP code that's safe to edit in FrontPage
By following some simple rules, it is possible for a developer to create Web pages with ASP code that can be safely edited in Normal View by end users in FrontPage 2000. Here are some tips to help.
- Write your ASP code in such a way that you can "lift" the ASP code out of the HTML code-and still have complete HTML tags.
- Keep all HTML tags separate from the ASP code. In particular, avoid splitting tags so that the opening tag is HTML and the close tag is part of the ASP code, or vice versa.
- Test the page and see if it opens in HTML View. If it does, make your changes, save and close the page, then open the file again to test to see if it opens in Normal View.
- Comment the HTML code preceding your ASP code to alert users that the code should not be changed. If a user opens an ASP file and changes the text above and below a table that implements ASP, but does not change any element within the table, the table is preserved "as is". Conversely, if a user deletes a tag or inputs a character or attribute within the table that implements ASP, the ASP code has changed and may not work correctly.
Additional Notes About Using ASP in FrontPage
Here are a few more tips for making ASP files and FrontPage work well together:
- Editing SELECT and OBJECT tags. Do not edit the SELECT or OBJECT tags using the FrontPage user interface. Use the Script Editor instead. When you edit the properties (contents) of a <SELECT> or <OBJECT> tag, that tag and all of its children get rewritten. The new copy will contain all of the <OPTION> or <PARAM> tags that were specified in the properties dialog, but any ASP that was in the original version runs the risk of being moved or lost.
- Previewing Active Server Pages. You will not be able to preview the ASP-generated content of a page using the Microsoft FrontPage 2000 Preview view. However, you can view the ASP files by selecting Preview in Browser from the File menu, as long as you are making changes to file that is on a "live" server running an ASP-capable server like the Microsoft Internet Information Server.
- Enabling the use of Active Server Pages in a Web is a "creation block for authoring" feature and should not be confused with enabling the use of Active Server Pages within the FrontPage 2000 user-interface. If a programmer does not want ASP to generate code within FrontPage, selecting the Tools menu, clicking Page Options, then the Compatibility tab and clearing the Active Server Pages check box will restrict all features that require ASP.