Navigation Home Search Site map
Contact Graeme Home Email Twitter
Math Help > Webmaking > ASP Net > ASP Net: Conversion from FrontPage to ASP.Net
I bought a new computer, which came with the Vista operating system, and took this opportunity to install the latest Microsoft Office software. I expected the latest FrontPage to be a part of this software, only to discover Microsoft has stabilized FrontPage, and that they have announced in so many words that FrontPage is old, and the clever little dodads that go with it will not be supported much longer. The writing on the wall is that Expression Web is the way forward, and the old dodads should be replaced by ASP.Net dodads.
This page (or section, if it gets too big) gives my experience converting from FrontPage to the more modern combination of Expression Web (for development) and ASP.Net (for the dodads and execution)
I should say Expression Web is one of the Web Development environments -- Microsoft also offers SharePoint for collaboration-enabled websites, and perhaps other software for more advanced web design. But for my little website, Expression Web is the way to go.
Converting from FrontPage to Expression Web is reasonably straightforward, with the following exceptions, which I would like to bring to your attention.
The Navigation View of FrontPage was extremely useful is now gone. There is no good replacement for this view, even though the navigation information itself has an architected home in ASP.Net, which is web.sitemap (described below)
A big improvement of Expression Web, as compared with FrontPage, is the Expression Development Server, which runs on your desktop computer whenever you hit the "preview" button to look at a web page. This is a full-function ASP.Net personal web server, that implements all the ASP.Net gizmos, including executing all the server-side scripts that may be present on your web pages. This allows you to develop locally, and test out all the features of your website, including sending email, and navigation, which are the two things I've tried so far, as I write this.
( . . . . . . this section should be moved to its own page, with an overview described here.)
Conversion from Frontpage Navigation is accomplished using the following manual procedure:
Find structure.cnf in the _vti_pvt folder of the FrontPage web.
copy it to (or open it in) notepad
change all \, to xyzzy (because commas in web page titles are escaped by \)
load it into the RawData sheet of a spreadsheet (SiteMap2.xlsx, which I'll describe a bit better in a minute), using text-to-columns splitting on commasChange all xyzzy to , (comma)
Add a "seq" column with sequential numbering, so that after sorting, I can re-sort it back into the original form
The raw data contains PageNumber, Source, D, Title, Parent, Data, and H. The important data here is the PageNumber, which is a unique identifier of the page, Source is the filename or URL of the page, Title, which is the navigation heading of the page, and Parent, which gives the parent page. This information is enough to build the ASP.Net web.sitemap data, which feeds into the ASP.Net navigation tools.
The next step is to copy the raw data to the first 8 columns of the "CookedData" spreadsheet, which contains some clever (if I say so myself) formulas to recursively follow the path up to the root from each page, traversing parent to parent until it gets to a page without any parent. The result is a sequence of "child numbers" of each page. That is, if I am the 3rd child of my parent, and my parent is the 7th child of the root (which is numbered 01) then my child sequence is 010703. Then, by sorting by this child number, the pages become sorted in exactly the sequence needed for the asp.sitemap page.
Another column of formulas gives the text itself of the web.sitemap page, which is the initial conversion from FrontPage. Here are the CookedData columns in enough detail for you to reconstruct the spreadsheet, and do your own conversion:
Column A: Seq -- numbers from 1 to 698. Not used, but I guess helpful if I ever wanted to put the data back in its original order.
Column B: PageNumber -- the FrontPage-assigned page number, a four-digit number starting at 1000. The largest number in my web was 1705.
Column C: Source -- the filename (URL) of the page.
Column D: D -- not used. Contains 0 in every record.
Column E: Title -- the title of each page.
Column F: Parent -- the FrontPage-assigned page number of the parent of this page, or 0 if no parent (i.e. a root node)
Column G: Data -- a ten-digit number, not used.
Column H: H -- not used. Contains 0 or 1. Does it mean "hidden"?
Column I: PageSeq -- a calculated field, giving the child-numbers in the path to the current page. For example, 010703 means the path starts from the 1st root, then its 7th child, and then the 3rd child of that node. The formula (using row 2 as an example) is
=IFERROR(OFFSET(I$1,MATCH(F2,B:B,0)-1,0),"")&RIGHT(101+COUNTIF(F$1:F1,F2),2)
Column J: Web.Sitemap -- a calculated field, giving the statement in the web.sitemap file itself. The formula is
=SUBSTITUTE(SUBSTITUTE(REPT(" ",LEN(I2))& "<siteMapNode title="""&E2& """ description="""&E2&""" url=""~/MathHelp/"&C2&""""& IF(I2=LEFT(OFFSET(I2,1,0),LEN(I2)),">"," />")& REPT(" </siteMapNode>",MAX(0,(LEN(I2)-LEN(OFFSET(I2,1,0)))/2)),"& ","&"),".htm",".aspx")
This gives you a great start, providing all of the "siteMapNode" statements that you will need. There are some additional things that must be done, though, which include:
Add the <siteMap> statement at the top, and </siteMap> at the bottom.
Pay close attention to the possibility of multiple root nodes. This is not allowed by ASP.Net. This spreadsheet will happily create multiple highest-level siteMapNode statements. The solution is to create a new highest-level siteMapNode, with either a null description, or one that points to a new "meta root" node that will be used in TreeView's, Menus, and SiteMapPaths (described elsewhere under ASP.Net Navigation tools)
Finally, it seems this spreadsheet throws out an extra </siteMapNode> at the end, which needs to be deleted.
As I mentioned, above, the result is a bit dense. It indents, at least, which helps you see the structure. But it is most helpful to add comments that provide large stary box titles. So, the major sections can be set off by
<!--******************************************************************* *** *** *** Chapter *** *** *** **********************************************************************-->
and then the sections (one level down) can be set off by
<!--~-~-~-~-~-~-~ Section -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-->
Notice the use of alternating hyphens and tildes. This is because two hyphens in a row aren't permitted in XML comments.
Thereafter, comments can be added to web.sitemap to help make the structure more visually evident, and further updating can be done manually, as described in my lament over the loss of the FrontPage sitemap.
( . . . . . . this section should be shortened, and its more expansive content moved to ASP Net: sending email )
I had developed a rudimentary form for this website, that allows users to enter their name, email address, and a comment. Using the "document.referrer" method, I also captured the web page the user came from, which is useful information to understand his comment.
At first, this web page used the FrontPage component that allowed form contents to be emailed to a particular email address.
Later, I created ASP pages using the Jmail software package provided by my hosting company. (They also offer "Bamboo", which is similar.) Then, when I tried to convert this application to work on an ASPX page, I found that I ran into security issues. I didn't have sufficient authority to execute this software package. After long googling, I ran across a large number of questions regarding getting these security issues solved in the ASP.Net environment, with various answers having to do with detailed web server security settings, none of which made much sense to me -- all over my head, I'm afraid. Then, I came to a very short response to one of these questions, "why don't you just abandon JMail (or Bamboo), and just use the email service provided by ASP.Net?
So if your ASP pages contain statements such as
set msg = Server.CreateOBject( "JMail.Message" )
or
set smtp = Server.CreateObject("Bamboo.SMTP")
Then you should do the following:
Begin (in server-side VB) with
Dim objMail As New MailMessage()
and then continue by setting the properties of the objMail object, after which the email is sent in a "try" block using
SmtpMail.Send(objMail)
with a "catch exc as Exception" to catch any errors, storing the details in the exc object, which can then be displayed on the page.
In FrontPage, you could make standard header and footer elements on each page, (and left and right elements as well) with standard content. In addition, each site could have a theme that provided standard styles of headings h1, h2, h3 etc. as well as list bullets, etc.
I had only top and bottom borders, so I implemented them using server-side "include" statements, which look like this, one right after the <body> and the other right before the </body>:
<body> <<!--#include file="index_top.htm" --> --- page contents go here --- <!--#include file="index_bottom.htm" --> </fo</body>
The top section contains a table that has an <h1> header with javascript that writes the page title in big letters, so the same top section can be used with every page. It also contains a SiteMapPath element that gives the user the ability to see the path from the home page to the page he's looking at.
In the days since FrontPage was first unveiled by Microsoft, a lot of things have changed. Cascading Style Sheets (CSS) became a standard some time after FrontPage first came onto the scene, and FrontPage started offering the option to use CSS to implement the styles. But for whatever reason, I never took advantage of that capability, prefering instead to keep the styles I had designed as they were. So it was a big job to start over, and design the style using CSS that you see here. In a nutshell, here's how to implement a CSS style: Start by creating a file like the one I call MathHelp.css, and then in the <head> element of every page, put the following statement:
<link href="MathHelp.css" rel="stylesheet" type="text/css">
Then the MathHelp.css file itself contains any special styles (with names starting with a dot) as well as styles for each element (with the HTML element name as the style name). Here's a part of MathHelp.css:
body { font-family: Arial, Helvetica, sans-serif; background-image: url('MathHelpBackground.jpg'); }
A:link { color:#006666; }
A:visited { color:purple; }
A:active { color:red; }
A:hover { color: #FF0066; }
h1 { color: #cc0000; background: transparent; font-size:x-large; font-weight: bold; }
h2 { color: #cc2200; background: transparent; font-size:x-large; font-weight: bold; }
. . .
FrontPage had some great navigation tools. In development, the navigation view showed an organization chart of pages, in a tree structure. In the site itself, each page had a banner, and optional navigation elements.
I had written a few ASP pages, using a variant of visual basic (VB) inside special brackets <% and %> that denote server-side scripts. The easiest way to understand what is happening is that the scripts are programs that are executed on the server, and then the output of those programs become the web page HTML that gets sent to the user. The first step in converting these pages to ASPX format is to change the suffix of the page name from ASP to ASPX. Then, in trying to execute the renamed pages (by loading them up in my browser), I stumbled over a number of errors. I tried to capture them all in the page, Converting ASP to ASPX..
For ASP.Net objects, TreeView in particular, to work properly, they must be contained in a form with the runat="server" attribute. There can only be one such form in any page, and existing forms with post or get mode navigation to other pages may not be contained within (embedded in) this form. So . . . . . . additional work is needed to understand how to use ASP.Net ASPX pages to convert these forms!
My hosting company doesn't offer a way to directly mark a virtual directory as an application, which is done by checking a box using the IIS administration menu, which is not accessible to me. The hosting company did this for me, though. Unfortunately, this undoes whatever FrontPage did to allow the folder to be considered a subweb. In fact, FrontPage extensions were completely deleted as a result of this change. This meant I could no longer author on the website, but had to use FTP to copy the website to my local computer, and do authoring locally. Then, individual pages can be copied to the server, and the whole site can be "published" by Expression Web. Moreover, as I noted above, the local authoring environment provided by Expression Web includes a full-functioning web server, so the benefit of quick testing that I used to enjoy using FrontPage is no longer such an issue for me.
( . . . . . . split this out into a separate page, ASP Net: My standard page, where it should give the full anatomy of a page, including the common scripts, css, server form, top, contents, bottom)
The following border and navigation elements require renaming pages to have the "aspx" suffix:
SiteMapPath requires page be named with "aspx" suffix.
<!--#include "filename"--> requres page be named with "aspx" suffix.
TreeView requires page be named with "aspx" suffix, and form runat="server"
Well, that was enough. I ended up renaming all my pages to aspx after discovering these reasons. Every page requires the first two of these, and a large number of pages require the third. My "home" page was index.htm, so I named it index.aspx, but this didn't work as a home page, because the server didn't know it as a home page. So I want to make this absolutely clear to anyone reading this page:
The home page of your website must be named default.aspx. Otherwise the server won't recognize it as the home page.
ASP Net: sending email
Converting ASP to ASPX
ASP Net: My standard page
The webmaster and author of this Math Help site is Graeme McRae.