Using FrontPage as a Database Record Editor
My company just bought Small Business Server 2003, and a copy of FrontPage 2003 was included, so I’ve been playing around with it for the last week. Overall, a huge improvement over previous versions of FrontPage (it no longer messes with your stuff…).
It includes something that DreamWeaver has had for years: page templates. You can build a “shell” of a page and then specify certain areas as “editable.” When a user creates a new page from a template, he or she gets the shell and can only put code in the editable areas – the “protected” areas of the page cannot be changed.
This is pretty handy. But, more importantly, it leads to a cool idea: you could use FrontPage as a WYSIWYG front end to a content database. Users could use FrontPage to create a new article, complete with all its tools.
The key is that when you create a new page based on a template, the HTML code of the finished page looks like this:
<title>This is the Article Title</title>
Why is this important: it’s perfect for parsing. A regex could easily run through this and extract (1) the name of the field (“title” in this case), and (2) the content of the field (“This is the Article Title”).
Using a bit of VBA, you could build a little module in FrontPage that would pull all this data out and put it in a database somewhere (locally, or it could post it somewhere).
So a user creates a new page from a template, edits all the “editable areas” (think of them as database fields) in WYSIWYG mode with all of FrontPage’s formidable editing tools, then clicks a button and “converts” the page into a database record.
If they want to change the record, they can just open that file, edit it, then convert it again, over-writing the old record. Use the local file path as a record identifier. Or use the parent directory as a table name, and the file name in the directory as the key. Anything in the “article” folder gets inserted in the “article” table, etc.
I don’t know – maybe it’s totally impractical. Worth trying though.