HTML PLAIN reference V1.1
6. Summary and conclusions
Next: 7. Test results Up: HTML PLAIN reference V1.1 Previous: 5. Example and test
This was the easiest part and implemented first. As soon as the HTML parser was completed, every syntactic entity could simply be checked for occurring in the dictionary, and be replaced if it did.
This feature allows for a better structuring of the document, and especially the header and footer functionality can be tremendously useful, if used well.
This task involved setting up a table for all files, which was fairly easy to implement. Unfortunately, the filenames could not just be inserted by a simple lookup. Instead, many special variables (see Section 2.3.2) have to be set, and the path has to be adjusted (i. e. a relative path has to be derived from the absolute path).
Taking away all file management problems is a big relief for the web master, and greatly reduces the chance of broken links.
The part in the main parser that runs the macros is fairly simple. The macros themselves were not always easy to write, as there are many possible cases that have to be considered, and therefore the code for generating a set of links is sometimes a bit more complicated than anticipated.
It is not sure whether users will ever write their own macros; the supplied (though small) set of macros covers most of the functionality that a web page uses.
Because Perl is very good at handling strings, the preprocessor is quite fast. If only one or two documents have to be updated, the main time is taken by compiling the Perl scripts before executing them. Otherwise, macros using site maps or iterating through the whole file table account for the largest amount of time. This cannot be optimized by using C as the implementation language for the parser, because the macros will still be in Perl.
A fast CPU makes a big difference, because the I/O overhead is relatively low, especially after runninghtmlplain once (and all files are cached). The running time of the file table generator depends somewhat on I/O performance, but the speed of the main parser does not.
I found the performance satisfactory for myself, on a PC that is getting too slow for modern games. I have also tried the preprocessor on a new PC, where it is indeed quite fast (especially if no macros are used).
The insertion of header and footer tags into the document was a very hard task. It is not always possible to know where to insert a tag, but the program usually makes correct guesses. In some rare cases, the insertion still does not work correctly, but this problem could usually be worked around by using a ``glueHeader'' setting.
Section 5.3 covers most of the important functionality and should be sufficient for more experienced web page designers. A more detailed ``step by step'' tutorial would of course be preferable, but this could not (yet) be achieved due to time constraints.
The configuration tools are not perfect; in particular, the two list boxes do not work together properly, and the ``spreadsheet-like'' representation is not quite like a table either. This is mainly due to Tcl/Tk limitations; with a more advanced toolkit like gtk+ [gtk], the look and feel would be much better.
The main weakness is the fact that every configuration entry is presented in a list, as opposed to a hierarchical tree. This is because the configuration file does not include any metadata about itself, so a tree cannot be generated. Future versions may include this, yielding a much better (hierarchical) representation of the configuration options, like in Netscape Communicator. In Tcl/Tk, it is not possible to show such a tree (unless someone writes a new widget from scratch for it), so that newer version would definitely have to be written using the gtk.
Another flaw is that each configuration entry is treated as a simple string, regardless whether it is a flag, numerical value, search pattern or file path. This could be improved as well.
Since the emphasis is on the preprocessor and not on these auxiliary utilities, these features have not been implemented.
Of course there are always ideas left about what could still be implemented. With the deadline for the 1.0 release coming closer, some features had to be left out. They will be implemented later, if either the author needs these features or users ask for them.
So far, the file table is generated fully automatically, with no chance of manual corrections (they should not be needed under normal circumstances). However, there are some cases where manual changes are desired. Currently, this can be achieved by editing a second file and appending it each time afterplainfiles has been called. Later versions of that program may support more elegant ways of achieving this.
It may be helpful to have several names for one file. Currently, this can only be achieved by manually appending entries to the file table (see above).
These files can only be referred to as binaries. It would be nice to have the program extract the first text line as title and allow using ASCII files like HTML files (including having them appear in a site map etc.)
Linking to files on a different server (or just a different virtual server) has to be done through entries in the variable dictionary. In the case when the files are also present on the file system where the HTML documents are found, this task could be automated.
Usually the main page looks different than all the other pages. It would be preferable to have different templates for different levels of content (see Section 2.2.6). Indeed this will not be hard to implement, as documents are now processed ordered by ascending content level. This will allow for a fairly easy extension; each time when a higher document level is reached, a new template is loaded, overriding options of the old one.
Sometimes the value of a variable is not known beforehand. In that case, a cut down version of the parser is needed, which works as a CGI program and fills in the variables that were not known at ``compile time''. This is not very hard to implement, as the more complicated part has been already done.
Because there is no standard path where applications are installed in non-Unix operating systems, writing Mac (or even Windows) versions involves quite a lot of extra work. With the installation program (see Section 5.1.1), running the program under a non-Unix platform should now be much easier. The lack of possibilities for testing Windows and Mac versions prevents a fast progress, though.