Stiillife как CMS

Что требуется от CMS общего назначения для большинства простеньких сайтов?

Как правило, очень ограниченный набор функциональности - встраивание зааплоаженного или набранного в форме документа в дизайн, возможное добавление ссылки в меню и в общем-то всё. Wiki-like функциональности без CamelCase - достаточно.

Фактически, весь необходимый код в движке уже есть.

Осталось только ввести один-два дополнительных шаблона и научить Stilllife обрабатывать ошибку 404 и, если юзер обладает правами записи при проходе по ссылке на несуществующий локальный документ, предлагать этот документ создать.

Дополнительные возможности, такие как генерация списков новостей сайта как части главной страницы, генерация списков свеже опубликованных материалов и автоматическая генерация списков всех материалов в определенной директории будут уже востребованы далеко не всеми сайтами

Ввести принцип "изнанки" -когда url вида hostname/cgi-bin/stilllife/путь к странице всегда ведет на административный интерфейс управления этой страницой. Сейчас в форумной части обращение к такому URL без указания параметра действия является ошибкой.

В CMS-ной части, если путь директория, должен показываться список всех файлов с возможностью управления (редактировать, удалить, переместить), если файл - видимо, по умолчанию, сразу редактирование (с возможностью аплоада), если неhtml-ный файл, то сразу форма upload.

Сбор оглавления очень нужен для печатных документов. А для онлайновых я считаю правильным делать каждую главку (2-3 экрана) отдельным документом, а оглавление документом сверху. Конечно, сбор такого документа-оглавления нужен - но это вроде бы стандартно для CMS?

Длинный онлайновый документ очень неудобен юзерам с медленным Инетом. Я таковым часто являюсь (например, когда на работе перегружен внешний канал) и хотя бы поэтому считаю нужным поддерживать других таких же.

Но подумавши - может быть интересной возможность автоматом собрать из хедеров в главках описания для "головного" документа. Как я понимаю, должно делаться более-менее тривиально?

Ну и что касается "всего-то". Я и этого "всего-то" не видел в реализованном виде; обычно если делают визуальный редактор - то с физическим форматом. А программой-максимум было бы оффлайновое редактирование. То есть я могу у себя на компьютере (который может быть и виндовым, и юниксным) создавать контент, картинки к нему прикреплять, а потом закачать его на сайт. Это позволило бы работать над контентом сайта без надёжного канала (например в дороге - мобильный канал не надёжен), и было бы уже вообще ничем не хуже WYSIWYG HTML редактора, при сохранении очевидных плюсов CMS.

Если я правильно понимаю твою идею, это могло бы реализовываться локальной копией той же самой CMS? Базы-то нет - а переместить файлы с одной копии на другую должно быть более-менее возможно.

Я вчера немножко погуглил на тему свободных WYSIWYG-редакторов для web-форм. Более внимательно посмотрел штуки на две-три. ВО ВСЕХ есть работа с h*.

Возможно, её выключают уже дизайнеры конкретных сайтов. Поскольку дизайнеру трудно понять, что пользователь может мыслить не в терминах физического оформления. Точно так же как программисту трудно понять что пользователь может не владеть в совершенстве регулярными выражениями

Возможность автоматически собрать оглавление документа из заголовков страниц ничем не отличается от возможности поместить абстракт свежесозданной темы на страницу форума

Что касается медленного инета и больших документов, то тут я с тобой не согласен. Гораздо удобнее, чтобы пока ты читаешь начало документа, остальное спокойно подкачивалось. Это, правда, накладывает ограничения на дизайн. Но меня как пользователя сайтов ничто так не раздражает как статьи, например, на вашем cnews, разбитые на странички размером с экран, где для подгрузки каждой следующей странички нужно кликать по ссылке и ждать, пока она загрузится.

Разбиение документа на маленькие кусочки имеет смысл для справочников и словарей, когда оптимизируется случайный доступ. При последовательном доступе как раз единый большой документ удобнее даже на медленном канале

Что касается оффлайнового редактирования, то да, все что требуется для работы с сайтом в оффлайне - это web-сервер на локальном компьютере. Причем любой самый примитивный - Sambar, lighttpd, что угодно, лишь бы протокол CGI поддерживало.

Единственное, что при работе нескольких редакторов одновременно потрербуется процедура разрешения конфликтов. Стоит подумать об интеграции туда системы контроля версий, причем распределенной, вроде darcs. Для форума это не нужно, а для general purpose CMS пригодится.

Вкурил твой ответ внимательно. Пришёл к интересной мысли.

Мне всё-таки не нужно создание длинных документов прямо в CMS. ну и соответственно функции вроде оглавления в них.

Но не потому, что таких докмуентов не будет на сайте, а потому, что для таких документов я использую OO.org Writer. И если и сменю его - то на другую среду, созданную специально для создания таких вот длинных документов.

В CMS я стал бы именно "делать сайт". То есть готовить контент, непосредственно привязанный к данному сайту - структуру, новости, информационные страницы и т.п.

А сколь-либо длинные тексты я не пишу "на сайт", я их просто пишу как таковые. Они могут быть сначала размещены в одном сайте, потом на другом, а потом вообще в книге. Кроме того, длинные тексты я могу брать и у других авторов, у которых свои любимые инструменты, и в одном из типовых случаев _уже_ готовы сами тексты.

Создать более удобную, чем OO.org Writer и иже с ним (для меня это уже именно так, а вовсе не "Word и иже с ним"), систему подготовки длинных текстов можно. Я даже писал краткое ТЗ в своё время; там должна быть _только_ логическая разметка, но при этом - условно-визивиговое представление. Штука будет куда более легковесная, кстати.

Но это IMHO не должно иметь отношения к CMS, поскольку очень не хотелось бы ограничивать такую систему возможностями HTML. Она может работать с каким-то подмножеством DocBook или чем-то ещё в этом роде, и не должна быть привязана к понятию "сайт" - документ "самоценен" и может размещаться много где в много каком виде.

А от CMS хотелось бы штатного способа разместить "сторонний" документ, подготовленный в различных инструментах. В идеале - взять этот самый документ, но отформатировать в свой шаблон. Лично мне хватило бы такой обратотки ровно для исходника, полученного "родным" экспортом документа OO.org в HTML.

(На другую тему: я не смотрел standalone редакторы Web-форм, без CMS они мне не особо интересны. Просто нарезать какой-то HTML я и в OO.Org смогу).

Каким образом организовывать импорт -отдельный вопрос. Не исключено что для OO.o оптимальным способом будет поддержка DAV (чтобы делать Save As HTML прямо на сайт).

Универсальный вариант - копирование через clipboard всего документа в WYSIWYG-редактор в web-форме. Точно известно что это работает с вордом. Правда, в этом случае засада с картинками.

Аплоад документа через <input type="file"> - это необходимость на серверной стороне разбираться с форматами. Конечно, формат OO.o - вещь открытая и довольно простая для обработки. А с rtf уже имеется довольно большой опыт. Но в итоге конвертилка будет требовать столько же кода, сколько вся остальная CMS вместе с HTML::TreeBuilder

Если я подготовил документ в текстовом процессоре, я и оглавление там сгенерирую. Насколько я понимаю, в OO.o я вполне сделаю корректные HTML линки. Но не уверен насчёт ворда.

Конвертилку из других форматов я бы не делал частью самой CMS - это сильно другая функциональность. Я бы сконцентрировался на обработке uploaded HTML (включая картинки, уже в нём упомянутые), дабы по возможности загнать его в шаблон.

Да, сейчас понял, что у StillLife CMS есть парочка принципиальных (следующих из архитектуры) преимуществ для юзера (т.е. хозяина сайта). Причём как раз в секторе, где я. То есть я таки захочу в её бета тестеры, когда/если она будет.

Во-первых, меньше требования к хостингу - только cgi и некий один язык (как я понимаю perl?)

Во-вторых, если хостинг и того не предоставляет, можно гонять CMS у себя локально, а потом попросту миррорить (хоть по фтп) на хостинг результат. При этом _все_ вкусности CMS, кроме оперативности, сохраняются.

Уфф... Я этот текст уже набирал один раз, но он куда-то делся. :-( Вторая попытка:

Когда Витус только замышлял Коммунивер (на Спиридоновке дело было), я писал ему письмо, в котором предлагал идею разнесения сервиса структурирования информации (собственно CMS) и сервиса раздачи её читателям (обычный файловый хостинг). Тогда мне не пришёл в голову вариант CMS прямо на пользовательской машине, потому что я представлял себе модель использования "сравнительно немного (но больше одного) авторов и гораздо больше читателей". То есть на одном сервере мы можем запускать программы, но у нас сравнительно узкий канал, а другой -- файловый хостинг: отдаёт только статику, зато много. На самом деле деление на "авторов" и "читателей" проходит не по людям, а по транзакциям: человек может прочитать сотню страниц с быстрого тупого файлового сервера и потом написать одну на медленном, но умном. Помнится, я тогда не помнил слова "аутсорсинг" (то есть знал смысл понятия, но не помнил, как звучит), и предлагал путь развития Коммунивера как сервис структурирования информации с "это самое слово, Левенчук знает" её раздачи читателям. Найти бы сейчас то письмо...

Немножко в сторону: авторы всех "упрощённых" языков разметки (да, я знаю, что у нас всё хранится в HTML, но) делают одну и ту же ошибку: как только дело доходит до возможности написать ссылку вовне, они придумывают синтаксис с url'кой прямо в тексте. Это и классический HTML с его a href, и вики с её [ссылка описание]. Это всегда очень неудобно. И только авторы reST (хотя, может, и не только -- я не утверждаю, что просмотрел _все_ проекты) сделали умнее:

For the syntax of URIs see RFC2396_ and RFC2732_.

(ниже, где угодно)

.. _RFC2396: http://www.rfc-editor.org/rfc/rfc2396.txt
.. _RFC2732: http://www.rfc-editor.org/rfc/rfc2732.txt

Я не уверен, что нам нужен отдельный _язык_ (и даже практически уверен в обратном), но идея выносить ссылки в отдельное место при взгляде с изнанки мне тоже очень нравится.