Why did I write another static site generator
First, I think you need to introduce yourself. I am not a programmer, programming is rather a hobby for me, and even from modern languages at the time of writing my bike, I only knew Java Script (and some Java). So I’m sharing not a programmer’s experience, but a look at the static site generators from the user’s side.
I had a saytik, with a small attendance and articles in the style of "me and my ... nice cat", which I regularly replenished. And, of course, I tried to tie some CMS to it. At first it was a wiki engine, then something more blogging. With a small attendance and weak hosting resources, I, of course, thought about translating the site to 100% static.
I expected to find a suitable generator, convert the records from the database of the engine to the files and rejoice. But it was not there. First came webgen, but the phrase “the source file may contain several blocks of text, for example, the main text and the text in the margins” immediately turned away from it. It was important for me to separate the content and the presentation, and this approach did not suit me.
')
Then I tried almost everything that was “on the market”, and I began to form a list of important “not”.
Many engines require a specific file name format, and perhaps 70% of all use an extension to indicate a simplified markup language (.md - Markdown, for example). The file name is just the identifier of this piece of data, you should not put too much on it.
It is more convenient for me to specify all the metadata uniformly, and the file header is suitable for this. Or site configuration file. At this stage, the wonderful Jekill, for example, has disappeared.
Why, then, generally a static site? In principle, making links like “/top-level/dir/file.html” is easier to program, but this rules out the possibility to view the site, say, from a flash drive. And requires running the server to preview. So I made relative links for myself.
The structure of the site is just the directories and files in them. Menu output is a template business. A separate function for setting the menu, of course, can facilitate the creation of a template, but makes the process less flexible. Then many engines disappeared at once ...
It would seem, what is easier - you write a text file. I liked to set the metadata at the beginning in YAML format, but all this is great as long as your native language is English. The interface of the usual CMS is Russified, why, going to the static site generator, I have to write:
This is, after all, ugly. On the other hand, it is better for a template engine to have uniform names, so in my generator I made a translation from localized field names to internal ones.
At one time I really liked the language TAL. Against it, other template engines looked a bit poor, and, most importantly, TAL is the most design-friendly. In the process of developing a template, you can simply watch it in the browser, and the “revitalization” of the finished one takes no more than half an hour. I even found a static site generator using TAL (PubTAL), but it’s heavily geared towards blogs, and…
And even for a blog, navigating through the calendar is not very convenient (in my opinion). So I did not consider the engines that order posts mainly by dates.
In my opinion, storing the site code and sources in the same directory is not good. There is an installation directory for the program, all the plugins should go there, and in the site directory only the configuration file for them should remain. However, for some reason, this decision did not occur to all the developers of such projects. Besides, I planned to launch not one site on my engine, but to keep track of, in fact, several installations of the program are lazy.
Although the ability to add to the site directory some site-specific code that solves local problems, I still added it in order not to litter the plug-in directory with too “private” tasks.
No matter what structure of the site the programmer comes up with, the user will want another. Therefore, in my opinion, all features of the directory structure - both the source code and the finished site - are customizable and, if possible, arbitrary.
For example, categories and tags are inconvenient to paint in advance, at the same time, it is not difficult to do all the necessary work on their generation with a simple list of tags in the file header.
It is more “yes” than “not”, but still important. For example, if one article is assigned the tag "Cat" and the other is "CAT", they are, of course, listed under one tag, but when you display the tags of a specific article, the spelling should be kept copyright.
It turned out that there will be no freebies, and any of the dozens of generators must be finished, or endured. So I thought that writing my bike wouldn't complicate things too much. Just had a lot of free evenings ...
At first I tried to write in PHP, because I thought that for the web it would be nice to study it better (I read it with a dictionary), but I didn’t go at all. The first version was on Pearl, then moved to the third Python. In a fully operational state, the generator spilled only about a year later. Now on this generator launched and working saytik.
Of the things that I (probably) came up with myself, I will mention the custom tag transliteration rules (I, for simplicity, use transliteration as a primitive "stemming"). That is, it seems to me a good idea if you can set the tags for “game” and “game” to be accepted by the system as the same.
Here is an example of the source file:
Where did it go
I had a saytik, with a small attendance and articles in the style of "me and my ... nice cat", which I regularly replenished. And, of course, I tried to tie some CMS to it. At first it was a wiki engine, then something more blogging. With a small attendance and weak hosting resources, I, of course, thought about translating the site to 100% static.
And rushed
I expected to find a suitable generator, convert the records from the database of the engine to the files and rejoice. But it was not there. First came webgen, but the phrase “the source file may contain several blocks of text, for example, the main text and the text in the margins” immediately turned away from it. It was important for me to separate the content and the presentation, and this approach did not suit me.
')
"NOT"
Then I tried almost everything that was “on the market”, and I began to form a list of important “not”.
File names should not affect the appearance of the site, as well as their extensions
Many engines require a specific file name format, and perhaps 70% of all use an extension to indicate a simplified markup language (.md - Markdown, for example). The file name is just the identifier of this piece of data, you should not put too much on it.
It is more convenient for me to specify all the metadata uniformly, and the file header is suitable for this. Or site configuration file. At this stage, the wonderful Jekill, for example, has disappeared.
The site should not require a server to view
Why, then, generally a static site? In principle, making links like “/top-level/dir/file.html” is easier to program, but this rules out the possibility to view the site, say, from a flash drive. And requires running the server to preview. So I made relative links for myself.
The engine should not have the function “menu”, “side panel” and so on.
The structure of the site is just the directories and files in them. Menu output is a template business. A separate function for setting the menu, of course, can facilitate the creation of a template, but makes the process less flexible. Then many engines disappeared at once ...
Creating an article should not be difficult. Not by how much
It would seem, what is easier - you write a text file. I liked to set the metadata at the beginning in YAML format, but all this is great as long as your native language is English. The interface of the usual CMS is Russified, why, going to the static site generator, I have to write:
title: date: 01-01-2012 This is, after all, ugly. On the other hand, it is better for a template engine to have uniform names, so in my generator I made a translation from localized field names to internal ones.
Simplified template engines are not needed.
At one time I really liked the language TAL. Against it, other template engines looked a bit poor, and, most importantly, TAL is the most design-friendly. In the process of developing a template, you can simply watch it in the browser, and the “revitalization” of the finished one takes no more than half an hour. I even found a static site generator using TAL (PubTAL), but it’s heavily geared towards blogs, and…
Not every blog site
And even for a blog, navigating through the calendar is not very convenient (in my opinion). So I did not consider the engines that order posts mainly by dates.
Do not interfere with the code and text
In my opinion, storing the site code and sources in the same directory is not good. There is an installation directory for the program, all the plugins should go there, and in the site directory only the configuration file for them should remain. However, for some reason, this decision did not occur to all the developers of such projects. Besides, I planned to launch not one site on my engine, but to keep track of, in fact, several installations of the program are lazy.
Although the ability to add to the site directory some site-specific code that solves local problems, I still added it in order not to litter the plug-in directory with too “private” tasks.
CMS developer should not invent the structure of the site
No matter what structure of the site the programmer comes up with, the user will want another. Therefore, in my opinion, all features of the directory structure - both the source code and the finished site - are customizable and, if possible, arbitrary.
No need to do in advance what can be generated in the process
For example, categories and tags are inconvenient to paint in advance, at the same time, it is not difficult to do all the necessary work on their generation with a simple list of tags in the file header.
No need to think for the user
It is more “yes” than “not”, but still important. For example, if one article is assigned the tag "Cat" and the other is "CAT", they are, of course, listed under one tag, but when you display the tags of a specific article, the spelling should be kept copyright.
What happened
It turned out that there will be no freebies, and any of the dozens of generators must be finished, or endured. So I thought that writing my bike wouldn't complicate things too much. Just had a lot of free evenings ...
At first I tried to write in PHP, because I thought that for the web it would be nice to study it better (I read it with a dictionary), but I didn’t go at all. The first version was on Pearl, then moved to the third Python. In a fully operational state, the generator spilled only about a year later. Now on this generator launched and working saytik.
PS
Of the things that I (probably) came up with myself, I will mention the custom tag transliteration rules (I, for simplicity, use transliteration as a primitive "stemming"). That is, it seems to me a good idea if you can set the tags for “game” and “game” to be accepted by the system as the same.
Pps
Here is an example of the source file:
: : 2012/3/1 10:18 : , , id: 115 # "" , . , --- ... <a href="/+id:123"> id - </a> Source: https://habr.com/ru/post/172571/
All Articles