Introduction

 Explanation

 Comparison

 Demonstration

 Documentation

   Quick start
   Terminology
   Site organization
   Templates
   Content files
   Page definitions
   Preferences
   Other components
   Tips and tricks
   Release notes
   Known issues

 Downloads

 Community

Known issues

This list includes aspects of Contemplate that we want to change, but that we're currently stuck on. If you have ideas about how to address these issues, !

• When using the replace attribute in an embed tag to do regular expression replacements, you can't use the character / (forward slash) in either your search or your replace string.
• Currently, the PHP and ASP versions of Contemplate will pass authentication information through the assembly process so that you can flatten a password-protected site. However, this feature is not included in the Perl version.
• In some cases, conflicts will occur if you give an embed tag the same name as one of Contemplate's internal variables. We're currently looking into an elegant way to prevent this problem in all cases.

Next steps

This list includes our plans for the next major release, Contemplate 2.0. if you have any comments about these plans.

• Use an HTML parsing module instead of regular expressions in the Assembler. Contemplate relies heavily on regular expressions (having originated as a Perl script), but these tend to be buggy and could be faster. We're exploring better ways to parse HTML content files.
• Support storage of content in a database. Contemplate was originally designed around the idea of using your favorite desktop HTML editor on standard HTML content files. But with the ongoing improvement of web-based editing components like TinyMCE, and the availability of fully-functional editors like Meditate, not to mention the ubiquity of database support on web servers, this has become a more useful option. With this approach, web developers would use the same tag syntax to retrieve content from database tables instead of HTML files.
• Store Reporter data in a database. The Reporter shows great info in a streamlined interface, but it bogs down when sites start generating a lot of traffic. Storing traffic data in a database rather than flat files should make this component much more robust.
• Simplify the Formulator. This component still has potential, but is difficult to use and maintain. A slightly more streamlined approach might hold up to real-world use better.
• Drop support for the Flattener. Running websites from a CD-ROM or hard drive is no longer common as it was in 1999 when Contemplate was first developed. Instead of maintaining the Flattener, optimizing the Assembler code for performance would be more useful.

Wish list

This list includes ideas that we're considering adding to Contemplate in the future, but we're either not sure how we want to implement them, or we just haven't gotten to them yet.

• It would be great if, rather than showing the current, very boring error message when it can't find a page definition, Contemplate returned a status=404 header so that the web server displayed its normal File Not Found page. The Assembler scripts already contain a line of code to do this, but none of them seem to have any effect.
• It would be nice if the functions that we've duplicated across various Contemplate scripts were saved in a single, shared file. However, we're not sure how to do this in the Perl version, and we might prefer to keep things as they are now to save one more file load during the assembly process.
• We should be able to rewrite some of the regular expression matching to use global matches rather than while loops, which should speed up parsing considerably.
• Currently, XML content files must follow the very simple document type definition shown in the demo site. However, we've not yet created a DTD file that documents this structure. More significantly, we haven't considered what it would take to make Contemplate support XML content files based on other DTDs.
• We think it would be cool to use multiple page definitions files in a site. However, we would then need to include the name of a page definitions file with every page request, like assembler.php?definitions=pages2.txt&page=foobar, and that might not be worth the extra clutter.
• It might be nice to format page definitions files as XML, but we're not sure. They can be a little hard to read either way.