This is another HTML pre-processor tool. When I was designing this, most of the cheap web-hosts had really restricted or absent dynamic page support. This project was designed to perform all the manual work, leaving you ~ the user ~ to just design. It was a recursive template renderer, and included URL checking. Although written in a UTF-8 capable language and for general reuse, I didn't have a UTF-8 enabled editor, so this aspect was over-looked.
This tool is obsolete. With current technology, I would recommend using a wiki or a blog platform.
The project code base also included some other documentation, as compilable targets. The results have been included as external files to this site:
Project outline I wrote at the time
This section is strongly influenced by CPAN which I was using frequently during my MSc. My use of language is currently more corporate. On reflection, this does demonstrate a CPAN influence again.
This project is a result of my dissatisfaction with available web authoring tools. I’m not sure that this is the correct answer to making web pages, but its wrong in different places. This software is targeted at projects that are large enough to require a structure, but small enough that you can hold the whole thing in your head. Its name starts with a lower-case ‘l’, and so cannot be used as the first word of a sentence. I would describe this as an HTML pre-processor, to provide some flavour of classification. It is not limited to generating web-pages, but any textual based media.
I, however, am awkward. I dislike repetitive effort, and design templates that I didn’t design. Interfaces (for people like me) should be designed to express my decisions, in the minimum time. As complexity and domain knowledge are less of a problem, languages are a stronger option. This is why twenty years after the first commercial GUI, all serious [technical] work is done via a shell. Another axiom is, work done once (and stored) should not need doing again. My tool is designed to in light of this perspectives. This does require more confidence in your control of the machine.
As writing good websites requires many different skills (which I tend to perform separately), the different aspects have been split up into different source files. See the included manual for a more detailed description. The compilation may require several minutes if link validation is performed, so the process is non interactive.
Distributed under the “the second artistic licence”, this is detailed 1
The current version of uk.org.noonshadow.linx is 1.2.2This requires (the whole cascade):
getOpt (in Java) was written by Aaron M. Renn and William King and is available 2
I acquired gnu.regexp at the same time.
linx 0.3-1.0 early summer 2002
basic language design, and thoery
hackHTMLparser as proof of concept
linx 1.0.1 August 2002
bug fixes, more stability
linx 1.1 August 2002
OpenLineParser (and internal restructuring)
extended language, with a few more primitives
(used to build documentation)
(and first real use “hoh project”)
linx 1.2 October 2002
IterateParser (extends concept of OpenLineParser)
adjust delimiting symbols for less clash with other languages (HTML)
code tidying, removed dead print statements
relinked to newer fileparser libraries
relinked to better debug macro (although unused)
linx 1.2.2 December 2003
moved output into properties files
altered package structure
added more line breaks to output, so its easier to read
- For maximum benefit, an internet connection to validate the hyperlinks with.
- A recent version of Java, and an equivalent Java compiler. This should be properly installed and on the path etc.
- The source of linx itself depends on a number of libraries. These have been included in the installation bundle. If you have several of my tools, you only need one copy of each library.
- ‘Bare skills’ at HTML etc.
- At the moment there is no included spell check, although this is top priority as a new feature.
- Extra file interpreters (so can read more complex formats than text/plain )
- There are some illegal inputs that induce a crash, rather than just failure. With these, check your input files before filing any type of bug report. Check all funny characters % that should exist in your result file are properly escaped.
- The source files must be encoded with same operating system as linx is run on. It doesn't care which operating system, as long as you do everything with it. Many text editors etc can convert between the different formats, which you would need to do in order to edit the files.
- Some errors are reported several times, with thread death. This is due the error propagation mechanism, the only thing that happens twice is the error messages.
- The file instruction is brittle under ms-windows. The symbols \ and : have two different meaning. This problem can be avoided by altering the linx language symbols (see linx.Constants), or running a variant of Unix.
% In the Perl sense of the word.