Classic Mac Workshop Site Overhaul
by Morgan Aldridge
WHY A SITE OVERHAUL?
The Classic Mac Workshop's site is easily editable by myself (the webmaster), but I have recently had offers to help with the upkeep and content of the site. Coordinating these changes will be slightly difficult and still relies on me to implement all changes, some system allowing others to modify the site would be greatly helpful. There are also some features I'd like to add which would be best implemented using some system of dynamically driving the site's content, one such feature would allow the user to specify whether they wanted the site rendered in a Text-only, Classic Mac OS, Mac OS 7, Mac OS 8/9, or Aqua theme.
With these issues in mind I have decided that moving over to a dynamic engine driving the site would be of great benefit to both the end users, the staff who contribute content, and myself.
THE DRIVING FORCE
There are many software solutions which would allow the site to be driven from dynamic content, this section discusses some of those options, which would be best for the site and for what reasons. Discussed are hardware and software platforms, server side scripting languages, and databases.
Since the site is designed to provide information about Classic Macs, I would like to use atleast a few as the driving force behind the site, but they definitely won't provide enough power to drive the whole site and all its content. The Classic Macs could probably handle serving mail, DNS, and possibly storage for content, but I'm not entirely sure yet (and I doubt it would matter too much whether they were running a UN*X OS such as NetBSD or the Mac OS). As for a more powerful server driving the site, I'd still like to use Apple hardware because I'm a Mac fanatic, so I've been leaning toward a PowerMac G3/G4 running Darwin and a set UN*X based content driving tools. Since the site doesn't get tons of traffic at this point even a Beige G3 should be sufficient.
Since I'm not entirely sure what part of the workload will be put on the few Classic Macs which will be involved, I'll start with describing all the necessary tools required run the entire site from a single G3/G4 box. Since I'm slightly partial to BSD operating systems, and the fact that this particular one supported an updated by Apple, the G3/G4 box will run Darwin. I don't want to bother licensing Mac OS X if I'm probably never going to use box with a monitor, so Darwin seems like the best bet for optimized performance on the G3/G4 and community support. Since Apache is free, is high performance, has many options for extending its capabilities, and is included with Darwin, it will be my choice for a web server. As for server side scripting languages, I have two options easily and freely available on Darwin: Perl and PHP. I have developed extremely complex web applications before using Perl, so I know it can be done, but I've also heard great things about PHP (an HTML embedded server side scripting language) so I'll have to do some further research into which would be best for the application. And lastly, for a database I will most likely use mySQL, it is reportedly the fastest database, it's free (or only $200 if I use it to sell any products), and can be built for Darwin. Depending on the performance, I may actually be able to set up a mySQL database on one of the Classic Macs running NetBSD for some of the less important databases.
POSSIBLE ENGINE STRUCTURE
So, if I move to dynamicly driven web content, how will the underlying engine pushing that content be structured? This is a very important question because currently the site is completely static content, but I would like to preserve the current organizational structure and appearance of the content. Since one of my goals is to be able to present the same content with various themes (mainly for browser side performance and appearance reasons) the content itself should probably be changed from its current HTML format to XML. Why XML? By using XML the HTML tags which are currently used to produce the Aqua theme of the site can basically be abstracted out to tags which can later be changed in-engine to produce the requested appearance, but HTML tags such as text formatting, links, and images can retained as straight HTML.
There should be a number of managers which provide the major features of the site, most likely separated out as follows:
¥ News Manager - for displaying, adding, searching and managing news (site and community/industry related)/
¥ Download Manager - for displaying, adding, sorting, searching, and managing downloadable files (including icons, descriptions, links, etc.)
¥ Links Manager - for displaying, adding, sorting, searching and managing links to external web sites (can provide an interface for abstracted links in docs to link to the same site, but the link would only have to be updated in the Links Manager).
¥ FAQ Manager - for displaying, adding, sorting, and managing frequently asked questions and their answers
¥ Article Manager - This would be the main manager which would allow for the displaying, adding, sorting, linking, searching, and managing, of articles within the site. This would handle everything from the main page with the links to various sections, to the listings for each section (including descriptions), to the actual articles.
¥ User Manager - Allow the displaying, adding, removing, managing and searching of user information. User information would be used for things such as logging into the site to gain access to features such as themes, various user stats, and more.
¥ Support Manager - For managing user support requests (providing stats) before they are sent through e-mail. Should probably include a feature allowing the e-mail to be redirected to alternate e-mail addresses depending on who happens to be doing e-mail support at the time (or in the case of domain changes, etc).
¥ Image Manager - (needed?) For displaying, adding, removing, managing images used on the site. Images are specified by unique name, but can actually result in different images being loaded for various themes.
Each Manager will have its own set of database tables which drive its content and its own API for passing arguments through URLs or generating content in-engine. Until I know what server side scripting language will drive the site's engine and managers I really can't determine exactly how the managers will be able to interact.
THE INTERFACE ABSTRACTION
This section describes the structure and use of the XML which will abstract the interface from the content. Note: This is only a preliminary version.
- This tag should be the outermost tag surrounding all of the document's content, specifying that it is a document, and also specifying the author and title.
- Can surround chunks of content. Specifies that the engine will render a window (with a theme specified in-engine) with the specified title and containing the specified content.
- Can surround chunks of content (usually an image). Surrounds the content with a picture frame rendered with the correct theme by the engine and having the specified comment.
- Surrounds a chunk of content (preferably an image or a textual name). Will produce a link to the document, specified by section and title (as found in the Article Manager), or an error page (if not found in the Article Manager).
- Surrounds a short string of text. Will produce a graphical header in-engine using the correct theme.
- Surrounds a chunk of content, preferably an image or text. Will produce a link to site (specified by the name which it is stored under in the Link Manager) surrounding the content.
- Surrounds a chunk of content, preferably the name of the download. Produces a link to a download page for the software (specified by the name the software is found under in the Download Manager), or an error page if the software can't be found in the Download Manager.
- Surrounds a chunk of content, preferably the user name. Produces a link to the info page for specified user (specified by name, as found in the User Manager). Especially useful for linking to author info.
- Specifies an image (as specified by name in the Image Manager), will produce the requested image, even for the theme if appropriate.
- Will produce a window (in the correct theme, of course) prompting the user to select a theme from a pop-up menu, including an OK button which will bring them back to their current location but using the selected theme.
- Will show the specified type of news (comma delimited list of: site, industry, community, etc), in the current theme, from start date (in MM-DD-YYYY format) to end date (same format, or 'TODAY').
- Will show one sentance summaries of the news (comma delimited list of: site, industry, community, etc), in the current theme, from start date (in MM-DD-YYYY format) to end date (same format, or 'TODAY').
- Will show today's date in Weekday, Month DD, YYYY format.
- Produces a window in the current theme, containing a text field and a search button which will search in the specified section in the specified manager (comma delimited list of: news, download, article, etc., all) and returns the results on a new page.
Basically the plan is that as the document is loaded that all such tags will be parsed and the correct managers will handle the custom generation of actual HTML from the tag. More tags may need to be specified for things such as news, themes, article sections, etc. There are many more features which will need to be implemented, some of them will need to be able to be generated dynamically, some not.
THE TIMEFRAME
This is a very complex overhaul for the site, it wonÕt be an easy process. I would expect it to take about 4 months to complete the way I would like. The problem is that I donÕt currently have 4 months free in which I can do this, keep updating the current Classic Mac Workshop, and do all the other projects IÕm involved with. I donÕt know when I can get to this.