StillLife: Свежие сообщения

Небольшое замечание по установке: в Fedora 10 в репозитариях есть все необходимые пакеты "родной" сборки, кроме HTML::BBReverse и Net::OpenID::Consumer.

HTML::TreeBuilder находится в пакете perl-HTML-Tree-3.23-4.fc9.noarch - кто бы догадался.

Вообще-то есть один вариант, но он ни разу не статичный, к сожалению. Вопрос в том, как рассматривать эту функциональность.

Если рассматривать её как поиск, т.е. функцию по определению динамическую, можно реализовать в достаточно ненапряжном для сервера варианте: при запросе берётся тот самый файл со ссылками на темы с участием рользователя и скрипт выбирает даты изменения этих тем.

Прогнозировать нагрузку сложновато - тем может быть и много и пользователи могут активно это всё пользовать. Это как бы вопрос приоритетов.

А ещё, насколько я понял, в конечном итоге будет экспорт в RSS/Atom, так что в какомм-то виде оно таки будет.

Отредактированное старое сообщение появляется в списке свежих реплик, если оно уже успело из этого списка уехать. Нужно в record_as_recent явным образом передавать флаг - добавлять сообщение или обновлять, если оно там есть.

Upd:Fixed

Если реплика имеет приаттаченные картинки, то в списке свежих реплик они не показываются. Потому что в текст реплики попадают относительные URL в той же директории что и сама тема. А страница "свежие реплики" живет совсем в другом месте.

Upd: Fixed
--

Высказываюсь.

Редактирую высказывание

Язык шаблонов StillLife в отличие от большинства других систем обработки шаблонов (включая Django, Communiware и php) базируется не на тексте, а на DOM-дереве HTML.

То есть любой шаблон представляет собой валидный HTML. В отличие от XSLT здесь нет специальных элементов, которые описывают действия. Всю необходимую функциональность несут классы (и иногда идентификаторы) элементов, благо в HTML 4.01 все элементы могут иметь атрибуты class и id.

Возможные конструкции языка шаблонв:

Подстановка значений

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

Условная подстановка значения

Здесь должны присутсвовать два элемента с указанными (разными) классами (а может сделать одинаковыми и проверять на вложенность?). Если подставляемое значение присутствует, то содержимое/атрибуты внутреннего элемента заменяется на это значение, и внешний элемент делается видимым, иначе внешний элемент делается невидимым или удаляется из сгенерированной страницы.

Условный блок

Если указанное условие не выполняется, блок делается невидимым/удаляется

Список

Здесь требуется два элемента с заданными классами. Сейчас класс объемлющего элемента делается из класса элемента списк добавлением list - message и messagelist, topic и topiclist. Объемлющий класс может включать в себя какое-то обрамление (заголовки, табличную структуру и т.д.) и как минимум один элемент. Если это элемент представляет собой щаблон-заготовку (например элемент списка сообщений в пустой теме, в которой ни одного сообщения еще не создано), скрывается весь список.

Если элементов больше одного, тэг-элемент списка со всем содержимым копируется и копия помещается непосредственно за предыдущим элементом.

Эти четыре метода обеспечивают мощность, сравнимую с системой шаблонов Django, правда, с той разницей что способ визуального представления подставляемых значений и условия по которым удаляются/повторяются блоки должны быть описаны не в шаблоне, а где-то ещё.

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

Вообще говоря, получается что-то похожее на MVC, с тем отличием, что в соответствии с концепцией "cайт это документ" контроллер предполагается сделать более-менее фиксированным.

Существующий скрипт forum на самом деле представляет собой жуткую смесь модели и контроллера. К сожалению, для того чтобы понять, как следует отделять модель от контроллера его надо было написать.

Опубликован скрипт, проверяющий все ли необходимые модули установлены на сервере.

Сам по себе скрипт требует только perl и CGI.pm, который с давних пор входит в дистрибутив Perl.

Скопировать этот скрипт в директорию cgi-скриптов вашего сервера и сходить браузером на URL http://ващ-сервер/cgi-bin/hostinfo.

Тестирование нескольких доступных хостингов показало, что все не так страшно, и те модули, где имеются откомпилированные части (что нетривиально для установки) как правило, везде есть.

Юзерпик молча не виден. Оно точно так положено?
--

В списке тем - положено

И вообще я не дизайнер. Поэтому очень хотелось бы найти дизайнеров, которые бы сделали 2-3 комплекта шаблонов, отлиных от базового. Разных.

Что касается ссылки с имени пользователя, то может быть ссылку на страницу со свойствами пользователя я и у локальных юзеров в будущем оторву. Когда появится OpenID продьюсер и у локальных пользователей будут нормальные странички (блоги). Сейчас она ведет туда потому что больше некуда.

Эту багу я уже заметил, но пока не дошли руки испаравить

В продолжение темы: два мелких неудобства не по движку даже, а по дизайну.

1) Ни со списка пользователей, ни со страницы редактирования своего профиля нельзя никуда уйти по ссылке -- на них просто нет никаких ссылок (в смысле на другие страницы натюрморта). Стрелка влево ещё годится в первом случае (посмотрели-вернулись), но совершенно неприемлема во втором: идти по истории назад после _действия_ (редактирования), а не _взгляда_ крайне противоестественно.

2) Неправильной кажется идея в списке пользователей давать для локальных пользователей ссылку на юзеринфу, а для опенидовских -- прямо на его урл. Было бы логичнее попадать на такую же локальную юзеринфу, а уже из неё по отдельной ссылке на его "родной" сайт. И, кстати, я не помню -- в спецификции опенид вообще требуется, чтобы он был реально ведущим куда-то урлом, или это просто такое имя в доменном пространстве имён?

На этой странице (и, кажется, на вообще всех, кроме корневой), ссылка "пользователи" показывает на

http://vitus.wagner.pp.ru/stilllife/users

, а не на

http://vitus.wagner.pp.ru/cgi-bin/forum/stilllife/users

Желающие могут сами проверить, куда идёт вторая, а куда первая. :-) Кстати, а в режиме "без разметки" ссылки распознаются? Вот сейчас и проверим...

Немножко в сторону: авторы всех "упрощённых" языков разметки (да, я знаю, что у нас всё хранится в 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

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

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

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

P.S. Чисто психологически неудобно без превьюшки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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