Сначала, думаю, нужно представиться. Я не программист, программирование для меня скорее хобби, да и из современных языков на момент написания моего велосипеда я знал только Java Script (и немного Java). Так что делюсь не программистскими наработками, а взглядом на генераторы статических сайтов с пользовательской стороны.
Откуда есть пошла
У меня был сайтик, с небольшой посещаемостью и статьями в стиле “я и моя… славная кошка”, который я регулярно пополнял. И, конечно, пытался прикрутить к нему какую-нибудь CMS. Сначала это был wiki-движок, потом — нечто более блоговое. При небольшой посещаемости и слабеньких ресурсах я, конечно, задумался о переводе сайта на 100% статику.
И понеслась
Я рассчитывал найти подходящий генератор, конвертнуть записи из базы данных движка в файлики и радоваться. Но не тут-то было. Первым под руку попался webgen, но фраза “исходный файл может содержать несколько блоков текста, например основной текст и текст на полях” — сразу отвратила от него. Для меня было важно разделить содержимое и представление, и такой подход мне не подходил.
“НЕ”
Далее я испробовал почти все, что было “на рынке”, и у меня начал формироваться список важных “не”.
Имена файлов не должны влиять на вид сайта, как и их расширения
Многие движки требуют определенного формата имен файлов, и, пожалуй, 70% всех используют расширение для указания языка упрощенной разметки(.md — Markdown, например). Имя файла — это просто идентификатор этой порции данных, не стоит возлагать на него слишком много.
Для меня удобнее указывать все метаданные единообразно, и для этого подходит заголовок файла. Либо конфигурационный файл сайта. На этой стадии отпал, например, прекрасный Jekill.
Сайт не должен требовать сервера для просмотра
Зачем тогда вообще статический сайт? В принципе, делать ссылки вида “/top-level/dir/file.html” проще для программирования, но это исключает возможность посмотреть сайт, скажем, с флешки. И требует запуска сервера для предварительно просмотра. Так что у себя я сделал ссылки относительными.
У движка не должно быть функции “меню”, “боковая панель” и так далее
Структура сайта — это просто директории и файлы в них. Вывод меню — дело шаблонизатора. Отдельная функция для задания меню, конечно, может облегчить создание шаблона, но делает процесс менее гибким. Тут отпало сразу много движков…
Создание статьи должно не должно быть сложным. Ни на сколько
Казалось бы, чего проще — пишешь текстовый файл. Мне понравилось задавать метаданные в начале в формате YAML, но все это здорово, пока ваш родной язык — английский. Интерфейс обычной CMS русифицируют, почему переходя на генератор статических сайтов я должен писать:
title: В лесу родилась елочка
date: 01-01-2012
Это, в конце концов, некрасиво. С другой стороны, для шаблонизатора лучше иметь унифицированные имена, поэтому в своем генераторе я сделал трансляцию из локализованных названий полей во внутренние.
Упрощенные шаблонизаторы не нужны
В свое время мне очень понравился язык TAL. На его фоне другие шаблонизаторы выглядели немного бедно, а, самое главное, TAL — самый дружественный к дизайнеру. В процессе разработки шаблона можно просто смотреть его в браузере, а “оживление” готового занимает не более получаса. Я даже нашел генератор статических сайтов, использующий TAL (PubTAL), но он сильно заточен на блоги, а…
Не всякий сайт — блог
И даже для блога навигация “по календарю” не слишком-то удобна (на мой взгляд). Так что движки, упорядочивающие посты в основном по датам, я не рассматривал.
Не надо мешать код и текст
На мой взгляд, хранить код и исходники сайта в одной директории не есть хорошо. Есть инсталляционная директория программы, туда должны идти все плагины, а в директории сайта должен оставаться только конфигурационный файл для них. Однако, почему-то, это решение пришло в голову не всем разработчикам подобных проектов. К тому же, я планировал запустить на своем движке не один сайт, а следить, фактически за несколькими инсталляциями программы мне лень.
Хотя возможность добавлять в директорию сайта какой-то специфичный для сайта код, решающий локальные задачи, я все-таки потом добавил, чтобы не замусоривать директорию плагинов слишком “частными” задачами.
Разработчик CMS не должен придумывать структуру сайта
Какую структуру сайта ни придумает программист, пользователь захочет другую. Поэтому, по-моему, все особенности структуры директорий — как исходных текстов, так и готового сайта — делать настраиваемыми, и, по возможности, произвольными.
Не надо делать заранее то, что можно сгенерировать в процессе
Например, категории и теги неудобно расписывать заранее, в то же время, совсем несложно сделать всю необходимую работу по их генерации имея простой список тегов в заголовке файла.
Не надо додумывать за пользователя
Это скорее «да», чем «не», но все равно важно. Например, если одной статье присвоен тег «Кошка», а другой — «КОШКА», они, конечно, перечисляются под одним тегом, но вот при выводе тегов конкретной статьи написание должно сохраняться авторское.
Что вышло
Вышло, что халявы не будет, и любой из десятков генераторов надо допиливать, или терпеть. Так что я подумал, что написание своего велосипеда не слишком усложнит положение. Как раз выдалось много свободных вечеров…
Сначала попробовал писать на PHP, потому что подумал, что для веба его неплохо бы изучить получше (я на нем читаю со словарем), но он у меня совсем не пошел. Первую версию наваял на Перле, потом перешел на третий Питон. В полностью рабочее состояние генератор вылился только где-то через год. Сейчас на этом генераторе запустил и рабочий сайтик.
P. S.
Из вещей, которые я (наверное) придумал сам, упомяну о пользовательских правилах транслитерации тегов (я, для простоты, использую транслитерацию как примитивный «стемминг»). То есть, мне кажется, хорошая идея, если можно задать, чтобы теги “игра” и “игры” принимались системой как один и тот же.
Автор: bozman
