INFORMATION FOR...

Final Programming Design

Our final design was to treat our web site as a heirarchy of folders with xml and html data in each folder and web page. Properties such as author email address could be overriden at any level of the site or inherited from the folders above. This was relatively easy to program and was an intuitive data structure for web site.

However, we wanted to distribute the editing work throughout the College and we didn't want to teach everyone in the College to edit xml. Furthermore, we wanted a WYSIWYG interface for the actual HTML content and didn't want to write a GUI ourselves. Our solution was to use Macromedia Contribute for the editing interface and treat the documents as xhtml rather than xml.

A Sample Static Web Page

To illustrate our architecture, its easiest to look at a static web page and how it is rendered: http://www.ed.uiuc.edu/cio/about/intro.html

User Exprience

The user edits the following files using Contribute or Dreamweaver to affect a static web page. More advanced users edit the menu and properties files, while all authors edit content documents.

Menu Files: i.e. /oet/menu.html
Properties FIles: i.e. /oet/properties.html
Content Documents: i.e /oet/about/intro.html

Web Serving Process

The web server takes the following steps to serve the web page. See also web pub system diagram and page manager diagram.

The Microsoft IIS 5.1 web server gets a request for the URL http://www.ed.uiuc.edu/cio/about/intro.html
The rewrite ISAPI internally redirects the page to an Active Server Pages (ASP) application, though the browser's URL is not changed. The rewrite ISAPI is basically the same as mod rewrite for Apache.
The ASP application reads the appropriate menu.html, properties.html, content document, and derives browser information using browser detection.
The ASP application creates an XML document with all the data derived in step 3.
An XSLT is applied to the XML document to produce the final HTML document sent to the browser. A single XSLT is applied to for all web pages both static and dynamic: common.xslt Common.xslt is static so is stored in cached, binary form.

Summary of Data Used to Produce A Web Page

The general classe of data are used to produce the resulting web page. (see also web pub system diagram )

menu: menu for left column
browser detection: browser type and assumed capabilities
page properties: author name, author email, template type
bread crumb or pathbar: where the page is within the site.
content: xhtml for each content section of the final page

This data comes from a variety of sources including:

Content documents . These are the XHTML files edited via Contribute or Dreamweaver. There is one for each "static" page on the site. Screenshot in new window.
Menu files . These are XHTML files edited via Contribute or Dreamweaver that contain the menu for a given directory in the site. If a directory has no menu file, it inherits the menu from the directory above it. Screenshot in new window
Properties files. These are XHTML files edited via Contribute or Dreamweaver that contain properties for a given directory in the site. Properties might include the author's name or the type of image used in the banner. Screenshot in new window

Data from SQL server, XML over HTTP, and other sources . This type of data has an XSLT applied to it to convert it to xhtml before it is aggregated into the data.xml document. Examples of these types of pages are:

Page	URL	Data Source	XSL
Faculty Staff Directory	http://www.ed.uiuc.edu/cio/fsd	SQL Server stored procedures	fsdsubindex.xslt
Course Catalog	http://www.ed.uiuc.edu/eps/courseapp	XML from UIUC Web Services server	courseapp.xslt
Research Pages	http://www.ed.uiuc.edu/eps/frp	SQ Server stored procedures	frpsubindex.xslt

Browser detection COM object . This is kind of rough now, but we expect it to get better when we migrate the application to .net. This provides basic browser detection.
Site definition xml file. A single XML file defines root properties for the entire site.
File and Folder Location and URL.