Two Approaches to Formatting Content Stored in a Database
Now that you have a basic framework for the admin section, you can start building its functionality. In this task, you will create a form that enables users to input new Traveler's Journal entries, which take effect immediately. The form outputs to tbl_journal, which is the same table whose contents index.asp retrieves to display the Traveler's Journal.
But if you look at the Traveler's Journal, you'll notice that its contents are formatted. The title is in a heading (<h3>, to be specific), the author line is in a <p> tag with the author class applied, and each subsequent paragraph is in its own set of <p> tags. How can you capture content so that it can be marked up and formatted? You can take two approaches:
Separate each of the elements. With this approach, you create a field for the title in the form and in the database table. Then you dynamically populate an <h3> element with the contents of that record. You then add another pair of fields for the author, and so on. This is how the country profiles and tour descriptions were formatted so precisely.
Embed HTML markup in the database table. With this approach, part of the text stored in the database is HTML markup. When the record is retrieved, so is the markup. Since the server inserts this text as a part of the page, the browser doesn't know that it is dynamically generated HTML, and it renders just like it would any other HTML.
Each approach has different advantages and disadvantages, and they are not exclusive, so you can use a hybrid approach if you like. The advantage to separating the elements is that HTML tags are hard-coded in the document, and they don't appear in the database. One disadvantage of this approach is that it's limited to paragraph-level styles. That is, it is easy to store the entire title and bind it to an <h3> element, but it would be hard to italicize one of the words in the title. Another disadvantage is that it requires more fields in both the database and the form. If someone typed the Traveler's Journal in a word processor and wanted to transfer it to a form, they would have to transfer one piece at a time.
The embedded HTML approach has its own strengths and limitations. One strength is that you can format the content to your heart's content. You can italicize words, make them bold, turn them pink, and magnify them to 100 pixels if you want. The weakness of this approach is that it requires users to hand-code HTML. One of the goals of a CMS is to make it possible for nontechnical people to maintain content, so requiring them to hand-code HTML defeats a key purpose of having a CMS.
Some commercial CMSs include basic formatting GUIs, which enable users to format using HTML without ever seeing itthey just highlight text and click a B button to make the selection bold. Such a feature set is again beyond the scope of this book, but it is possible.
NOTE
The Traveler's Journal is one element that would benefit from Macromedia Contribute: users could replace it directly and quickly, and format it as they please. We'll go ahead and build a CMS for it, because doing so will give you exposure to concepts and techniques that you'll use over and over again.
In this task, you will take a compromise approach, in which users have to see some HTML markup, but they don't actually have to write any. They just overwrite descriptive placeholders in an already marked-up block of text that you set up as the default in a text area.
