Тут вчера у alexkuklin случился забавный флейм на тему того, какова должна быть идеальная CMS. Cудили рядили и выяснили что опять таки разных CMS сильно больше чем хороших.
Учитывая, что ikiwiki на которой в данный момент работает мой блог тоже как-то не очень оправдывает надежды, я задумался о том, не стоил ли вернуться к проекту StillLife.
По крайней мере завел для него раздел в wiki и написал Т.3. (с почти полным описанием декларативного DSL для описания вебсайтов).
P.S. Старая версия stilllife, которая на perl и с использованием HTML::TreeBuilder (новая будет на чем-нибудь другом, и на базе библиотеки для работы с XML DOM) сейчас не работает, не потому что сломана, а потому что заговорена. В смысле, скрипт удалён из cgi-директории веб-сервера. Но читать всё, что было написано можно. И в этом, кстати, одно из достоинств stilllife - даже если всё сломалось, сайт доступен.
Вск 20 Янв 2013 01:47:16
В таких документах самым вкусным обычно является rationale...
Здесь вот сразу возникают вопросы:
Вск 20 Янв 2013 06:15:32
XML -- зло. А уж XSLT -- тем более. Людей которые умеют этим нормально пользоваться можно пересчитать по пальцам.
Для темлпейтов есть прекрасные темплейтные движки -- CTPP прекрасен своим плагином для nginx, который умеет получать от скрипта JSON, а потом из этого JSON и темплейта генерировать уже что душе угодно. Ну и он действительно быстрый.
У JSON перед XML ровно один недостаток -- нет стандартного механизма валидации. Но для этой задачи он скорее вреден -- возможность добавить поле с данными, которое обрабатывает конкретный плагин, и который игнорируют все остальные это скорее плюс.
В качестве формата для хранения собственно контента -- таки лучше всего markdown.
В качестве формата для хранения различных метаданных -- JSON.
Любые эзотерические технологии имеет смысл использовать только если они дают какие-то killer features. XSLT сейчас можно считать эзотерической технологией.
Вск 20 Янв 2013 13:03:03
Потому что руками и глазами туда смотреть не надо, туда надо смотреть браузером.
Сайт не для программистов. Сайт для пользователей и, немножко, дизайнеров. Дизайнер должен знать HTML. Иначе у него ничего не получится сдизайнить, чтобы не разъезжалось. Поэтому можно не заставлять его учить что-либо другое. А пользователь работает всё равно через штатный интерфейс.
Это дает такие преимущества:
главная копия и то что отдается пользователю - одно и то же. Что имея только доступ по http к сайту, можно его склонировать. По добытой из кэша браузера страничке можно восстановить информационный объект, шаблон.
Если это не форум а информационный сайт, где кто попало писать не может, его можно в любой момент записать на сидюк, заархивировать зипом и раздать для оффлайнового просмотра. Потеряются при этом только пароли редакторов. И в любой момент этот оффлайновый документ можно опять поднять как живой сайт.
Вск 20 Янв 2013 13:16:49
Главное, что XML/SGML - единственное, что умеют понимать браузеры.
Вообще в идее, что плагины писать сложно, что-то есть. У пользователя не должно возникать желания сразу бросаться писать плагины. Он должен сначала немножко подумать, а нельзя ли решить задачу без них. 99% задач, которые действительно стоит решать, решаются либо в рамках предложенного DSL, либо с помощью внешних сервисов, интегрированных в сайт.
Предложенная система в бесконечное число раз быстрее любого вашего плагина, потому что она НЕ ВЫПОЛНЯЕТ НИКАКИХ ПРЕОБРАЗОВАНИЙ над контентом, отдавая его пользователю.
У нас Content Management System, а не Content Delivery System. Поэтому она вступает в дело только при добавлении и редактировании контента. То есть для форума - в сотни, а для сайта-визитки - в десятки тысяч раз реже, чем отдача страницы.
Смысла в JSON я не вижу. XML в интерфейс плагинов хорош тем, что введенный пользователем XHTML(через wYSIWYG радактор client-side, через client-side преобразовалку markdowm или ручками) туда естественно встраивается. Если мы не ставим задачу встраиваеть естественным образом пользовательский контент в прочие данные переданные запросом, то надо передавать данные байт-в-байт, как они пришли из формы. Парсить x-www-form-uri-encoded и multipart/form-data умеют всё равно все.
Вот когда браузеры начнут понимать markdown, мы об этом поговорим. И то вряд ли что получится, потому что пользователь хочет красивого дизайна. При отображении в браузее MarkDown это вряд ли получится.
Невизуализруемые данные в этой системе - исключение (пароли, если они есть, email-ы уже под вопросом, может их лучше и показывать). И для их хранения не нужен никакой структурированный формат. Проще каждый атрибут в отдельной dbm хранить.
XSLT это yet another язык. Хорош тем, что он непроцедурный. Плох тем, что предъявляет серьезные ограничения к формату входных данных. Если мы выдаем данные в таком виде, что их поймет ДАЖЕ XSLT, любой другой язык их тем более поймет.
Вск 20 Янв 2013 17:17:24
А использование HTML5 уже становится нормой, и валидный XHTML сейчас вообще мало кто делает. Кстати вот прямо в этом блоге невалидный XHTML -- br не закрывается. Какой процент нынешних вебмастеров в курсе того, что он должен закрываться? Большинство его не закрывают никогда, некоторые особо продвинутые его таки закрывают, но даже с doctype HTML5.
Насколько я в курсе, W3C забили на XHTML5, и хотя черновик был выпущен XHTML5 официально мертв.
Ну и на закуску, цитата из http://ru.wikipedia.org/wiki/HTML5 -- "Синтаксис HTML5 больше не базируется на SGML, несмотря на подобие его разметки".
Так что то, что в ближайшие годы будет стандартом де-факто в web -- не будет являться ни XML, ни SGML, а будет являться HTML5
По поводу внешних интегрированных сервисов согласен, если этим сервисам будет удобно работать с данными, без риска что-то сломать.
Вариант с темплейте на прокси -- я не прав был. В варианте "темплейтный движок отрабатывает при коммите" -- почему нет?
Мне очень не нравится идея, которую вы формулируете как ключевую фичу -- то, что контент отдаваемый пользователь и есть основное хранилище информации. Я все-таки предпочел бы видеть контент и представление контента совершенно разными объектами (второе обновляется по необходимости при изменении первого). Кроме ситуации с HTML5, у нас в любом случае будут разные версии документов (например отдельно для мобильных пользователей), или это тоже планируется все разруливать на client-side? Тогда тот, кто будет писать js-часть для этого проекта будет сильно рисковать своими нервами
А как связана красота и markdown? Речь о WYSIWYG-интерфейсе? Вот сколько я смотрю -- первое от чего бесятся пользователи, так это необходимость учить какие-то там тэги чтобы сколь-нибудь прилично оформить документ, а если их не учить -- мучаться в глючных js WYSIWYG-редакторах.
При этом тех же самых "простых юзверей" вполне устраивает использовать на форумах кошмарный bbcode.
Вск 20 Янв 2013 19:06:35
Не предполагается, что внешние сервисы (ну кроме поисковых роботов), работают с данными, управляемыми CMS. Не их собачье дело. Их дело - предоставить страницы, позволяющие работать с данными, которые не ложатся в парагигму CMS. Табличными, реалтаймовыми или еще какими. Эти сервисы как правило, каждый имеют свою собственную систему шаблонов и единственным общим знаменателем для них является именно html,
Что каксается того, что в данном блоге невалидный xhtml, так он вообще-то и не обещался быть xhtml-ем. Он html, то есть sgml-приложение, а не xml-прилоежние. В sgml-приложениях могут быть незакрываемые теги. Более того, теоретически никто не мешает, одну и ту же DOM сериализовать как sgml-приложение с определенной DTD, и как XML (а также как SXML и ещё много как что, хоть как ASN.1 CER).
Я не понимаю, зачем вам видеть контент отдельно от представления. Пользователь видит контент сайта либо в форме редактирования, либо на странице. То и другое, вообще говоря, представления. Всё остальное внутреннее дело движка. Его никто не видит.
Контент, отдельный от представления это виртуальная сущность, существующая только в памяти движка, в момент выполнения операции редактирования. Мы просто назначаем одно из альтернативных представлений основным хранилищем. А так альтернативных представлений может быть сколько угодно. Основное хранилище отличается от альтернативных только тем, что в нём хранятся все публичные атрибуты объекта, и, соответсвенно, мы их умеем оттуда вытаскивать.
Красота и markdown связана так, что если мы отдщаем пользователю markdown, и пользовательский браузер его самостоятельно рендерит, красоты там не будет. Потому что не предусмотрено в Markdown для этого средств. А в html - предусморено. Создание красоты это, естественно, не для пользователя, а для дизайнера.
Зачем нужны тэги, если по ним нельзя кликнуть, и попасть на страничку со всеми постами с данным тегом? Тэги - это вполне визуализированные данные. Так что пример неудачен. Тэг во-первых явным образом пристуствует в представлении поста, к которому он привешен, во-вторых имеет отдельную страницу. Тот самый "список похожих постов".
Вск 20 Янв 2013 23:33:08
Цитаты из русскоязычных мурзилок на темы, связанные с международными стандартами не аргумент. Пожалуйста, ссылку на англоязычный источник, причем желательно в домене w3c.org. Текст из английской википедии я еще согласен рассматривать. Но любой русскоязычный текст на компьютерную тему, не имеющий явно обозначенного автора, никаким авторитетом для не обладает.
Пнд 21 Янв 2013 08:54:27
Ну как же не обещался? DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN. Ну и валидатор со мной полностью согласен. Я это не к тому чтобы наехать, а к тому, что если уж вы со своим технологическим перфекционизмом не считаете это ошибкой, чего ожидать от обычных верстальщиков?
Контент отдельно от представления не существует даже в памяти движка, видимо, там тоже представление. Но это уже мы в терминологические споры ушли.
Суть в том, что вы хотите чтобы внутреннее представление, из которого генерируются различные внешние представления и одно из внешних представлений было одним и тем же объектом. Если это представление напрямую всегда отдается клиенту когда он заходит смотреть конкретную статью это вероятно имеет смысл, но на большинстве блогов даже страница просмотра конкретной статьи содержит массу контента, который генерируется на основе еще и других страниц (related posts, облако тэгов, меню навигации). И если последние два можно подгружать js из других документов, то related posts должны быть физически в том самом html, который мы отдаем пользователю -- ибо оно критически важно для SEO (см. "перелинковка страниц").
В итоге либо внутреннее представление текста статьи и то, что мы выдаем по http запросу конкретного документа это физически разные файлы (и одно генерируется из другого на равных правах с документами вроде "список постов за такую-то дату", "список постов по такому-то тэгу" и т.д., либо редактирование одного объекта должно приводить к прямому редактированию внутреннего представления неопределенного количества документов.
Как вы предполагаете реализовать те самые related posts?
Внутреннее представление контента своего ресурса вижу я. В случае с Wordpress я его, конечно, не вижу (потому что смотреть в БД -- нервы свои жалко). И меня лично невозможность пользоваться на собственном блоге git, grep и sed -- очень раздражает. Соответственно логично, что хочется иметь внутреннее представление пригодное для работы с ним руками, если только это не связано с чрезмерным усложнением системы, или потери какого-то другого ценного функционала.
Тэги нужны не только для кликов. Это часть системы классификации постов. При этом визуально отображаемые тэги это подмножество тэгов. Это опять же полезно для тех самых related posts -- не каждый может встроить в свой сайт полноценную систему анализа текстов, а автоматическое присвоение тэгов это такой "анализ текстов для бедных".
Если речь о крупном ресурсе, то тэгов используемых для классификации может быть тысячи, отображать их все смысла никакого.
Ладно, раз википедия не катит: вот, цитата:
По поводу прекращения XHTML5 ничего полезного не нашел сходу
Но зато нашел Polyglot HTML5. Это не XHTML, но это корректный HTML5, одновременно с тем, что это корректный XML. Если использовать его, то и овцы будут сыты и волки целы.
P.S. Вот то, что здесь можно писать в markdown а не мучаться с WYSIWYG или html -- это-ж счастье!
Зачем вы хотите заставить пользователей страдать? 
Пнд 21 Янв 2013 11:01:41
Да. именно так.
Да, ну и что? Ну содержит. Вы немножко подумайте о том, какое количество не относящейся к делу информации содержат те файлы, в которых лежал mysql-евские базы данных. Когда вы разрабатываете сайт, хранящий данные в БД, вы об этом не думаете, у вас есть язык запросов. Но для XML у вас тоже бывают языки запросов. Главное чтобы у нас были четкие инструкции как из DOM-дерева, в котором кроме собственно информационного объекта содержится дизайн, списки других информационных объектов да ещё хрен знает что, выдрать редактируемые атрибуты нужного объекта.
Я, правда, полагаю, что не нужно брать готовых XPath и XQuery, а вместо этого использовать что-то похожее на селекторы в CSS. Потому что CSS дизайнер обязан знать.
В любом статическом генераторе вебсайтов редактирование одного объекта приводит к модификации нескольких документов. Вопрос заключается в том, как четко описать правила поиска этих документов, чтобы не приходилось шерстить всю файловую систему, чем зачастую грешат эти самые статические генераторы, и как минимизировать затраты ресурсов на перегенерацию большой страницы с длинным списком объектов, если изменился только один из этих объектов. Генераторы сайтов, в которых внутреннее представление отлично от внешнего, в этих случаях обычно перегенерируют всю страницу целиком из внутреннего представления. Если внутреннее представление совпадает с внешним, мы можем позволить себе сильно соптимизировать этот процесс и не трогать представление тех объектов, которые не менялись.
Пнд 21 Янв 2013 17:09:45
Так, кажется осознал -- раз этот html будет использовать и как внутреннее представление, значит он будет чудесно парситься штатными средствами. А значит маньяк вроде меня сможет с легкостью прикрутить возможность редактировать этот html сконвертировав в произвольный формат (тот же markdown), отредактировать, и сконвертить обратно.
Тогда у меня остается лишь один единственный аргумент против хранения в html -- git. Вернее сам html, если верстать хоть чуточку по уму и расставлять переносы строк переживет git merge замечательно, но вот вот с комментами там надо формат разметки внимательно обдумать, чтобы оно не превращалось в кашу.
Согласен полностью. Особенно по поводу CSS-селекторов.
Однако если у нас редактирование и генерирование в одном флаконе, и при этом множество генерируемых и редактируемых объектов пересекается -- придется делать lock'и, и исключить возможность параллельного обновления нескольких страниц.
И вот тут самая большая неприятность -- лочить на зпись таки придется весь сайт даже при добавлении комментария (потому что кол-во комментариев на этой странице всплывет уже много где).
А вот тут как раз все сложнее -- там где внешнее представление отличается от внутреннего, можно генерировать блоки и cat'ом их объединять, по необходимости. Соответственно даже объединять надо только те страницы, блоки для которых изменились. make с этим прекрасно справится.
Обновлять всего лишь чуточку сложнее -- если вводится кэш в виде "совсем внутреннего представления". В котором отделены мухи от котлет (контент, комменты, генерат всякоразный).
В итоге все равно получается хранилище внутреннего представления данных, где мухи отделены от котлет. Правда, так как это всего лишь кэш, возможность сделать рабочую копию сайта wget'ов никуда не девается.
Пнд 21 Янв 2013 17:41:51
Вообще-то даже в ikiwiki, которая вся из себя построена на использование revision control, комменты чекинить в version management system необязательно. Ну то есть можно, и я это даже делаю, но необязательно. Для того класса задач, для которого планируется данная система, вряд ли в version management будет лежать что-то кроме шаблонов. Нужно предъявить мне какого-нибудь пользователя какой-нибудь вики, который не являясь программистом, активно пользуется revision control, встроенный в wiki-движок, чтобы я подумал о полезности интеграции с version management в данном проекте.
Во-первых, это не неприятность. Комментариев в блоге бывает от силы сотня-другая в сутки. Ну тыща. Во-вторых, у нас все dependency аккуратно прописаны в модели, поэтому мы можем лочить не весь сайт, а только те страницы, где это необходимо. В общем, простор для максимизации параллельности там есть. Но вообще работу с агрегатными функциями я совсем не прописал. И где в модели написать, что в списке постов в блоге (или в тэге) должны появляться счётчики количества комментоа в посте, мне пока не очевидно.
Но вообще, что самое интересное, на базе данного языка описания моделей и данной системы шаблонов в принцпие можно сделать несколько разных движков, с разными свойствами. У кого-то будет хранилище с представлением, отличным от html, у кого-то нет, у кого-то будет интеграция с git, у кого-то нет, и при этом, может быть даже удастся обеспечить простоту переноса сайтов между этими движками.
Пнд 21 Янв 2013 18:45:45
Сколько там пользователей у wikipedia? Какие там классные войны откатывания изменений и т.д. И ведут эти войны отнюдь не программисты -- так что пользоваться простейшим revision control юзвери умеют, если знают зачем им это надо.
Плюс тот же wordpress это блог + странички. И если для блога полноценный revision control нафиг не нужен (разве что история последних пары изменений, на всякий случай), то вот для pages -- нужен.
Тут самое смешное в том, что подобная архитектура, когда все статическое и генерируется, даже более выгодна для крупных ресурсов чем мелких блогов. А там в сутки может быть и больше тысячи комментов. Плюс, эти тысяча комментов не так уж и размазаны по времени -- есть четкие пики (при попадании ссылки на главную страницу крупного сайта, например).
Причем тут вот какая штука -- если человек отправил коммент, то он должен в течении максимум 1с получить на экране страничку, где его коммент уже есть. А вот если обновление счетчика комментов задержится даже на 10с -- всем пофиг. Если нагрузка небольшая -- это произойдет мгновенно, если большая -- значит вероятнее всего этих комментов не 1, и будет там 100500 или 100501 никто не заметит.
Так как часть контента все равно генерится, то в любом случае есть как парсер отдаваемого юзеру html, так и генератор. Так что перенос даже не надо особым образом организовывать -- любой вариант должен уметь сгенерировать html для пользователя. А значит его можно разобрать и импортировать.
Достаточно всего лишь не требовать использовать html как основной формат хранения, а изначально предполагать что это один из возможных форматов хранения.
Кстати, а почему бы не использовать для таких псевдодинамичных вещей, когда некий кусок дублируется в множество мест старый добрый ssi? Ну да, ssi это медленнее чем просто отдать с диска, но все же несравнимо быстрее чем скрипты.
И тогда какое-нибудь облако тэгов и прочие widget'ы могут спокойно лежать где-то отдельно, и вставляться сразу во все странички. На ресурсе с небольшой посещаемостью но большим объемом контента это будет даже выгоднее по ресурсам, чем перегенерировать весь сайт по каждому чиху.
Кстати, про те же счетчики, вполне может быть widget типа 'топ комментируемые посты', и тогда придется однозначно лочить весь сайт по каждому комменту.
Собственно главная мысль, которую я хочу донести -- у есть объекты FS содержащие первичный контент, и и есть объекты FS которые содержат только генерат. При каждом выполнении операции обновления единицы контента -- сколько будет модифицировано файлов с генератом, это вопрос производительности. А то, сколько будет модифицировано файлов с первичным контентом -- еще и вопрос надежности. Поэтому мне очень хочется выяснить есть ли вариант, который удовлетворяет вашим требованиям по производительности и удобству миграции (включая backup wget'ом), но при этом который не будет иметь очевидных граблей при масштабируемости. Особенно с учетом того, что во всем остальном предлагаемый вами вариант выглядит легко масштабируемым даже до масштабов ЖЖ.
Пнд 21 Янв 2013 19:07:45
Вот как раз крупному ресурсу статика не особо критична - он всё равно обречён иметь дело с CDN, на которую и ложится 99% нагрузки. Пришлось тут иметь дело с одним из крупнейших сайтов в США - тамвнутри жуть, страница может полноценно сохраняться десятки секунд если не минуты (конечно, предварительный вариант генерируется быстро), и выдаваться - единицы. И это никак не критично - CDN всё равно всё закрывает, а без неё не обойтись - хотя бы географическое распределение всё равно нужно, и машстабирование она обеспечивает надёжно. Кстати, там сейчас вроде даже от генерации статическихстаниц из базы уходят - неудобно новые фишки прикручивать, если найдена ошибка в шаблоне надо заново генерировать кучу всего... в общем, база + мемкеш + CDN лучше.
Подозреваю,что статика потому и не взлетает, что реализовывать её посложнее, чем динамику, а ниша, где она даёт выгоду, очень узка, обычно кэшированием прикрыться куда проще.
Пнд 21 Янв 2013 19:56:10
Пнд 21 Янв 2013 20:10:43
До меня только сейчас дошло -- полностью в рамках вашей концепции можно прекрасно отделить мух от котлет. В блоге есть widget'ы важные для SEO (такие как related posts), и они должны быть в самом html. Но их как раз не обязательно обновлять on-line. Если я опубликовал новый пост, и в связи с этим список related posts в каких-то других статьях должны поменяться -- произойдет это сейчас, через час, или вообще завтра совершенно не важно. Это можно делать по cron'у.
widget'ы типа "какие у нас сейчас самые комментируемые посты за последний час" для SEO не очень-то нужны, а значит их можно спокойно подгружать из js.
В принципе также можно подгружать и весь блок с комментариями, соответственно сам пост и комменты будут физически в разных файлах. А значит держать это все в git уже будет гораздо приятнее. Но комментарии могут быть важны для SEO.
Пнд 21 Янв 2013 21:18:07
Динамику не хуже. Но когда всё равно есть кэш в виде CDN преимущества статики теряются, в отличие от недостатков - ну там, необходимость перегенерить все 100500 статей если нашелся баг в шаблоне, или что-то выдумывать если мы хотим по каким-то критериям варьировать оформление (в том число SEO-значимую часть), или ещё что. Опят же - нет дублирования всего этого дела в куче представлений, что надо - попадает в кэш и там лежит, а большая часть старья, которое никто не читает, находится в базе и никому не мешает особо. Ладно, всё это о крупных проектах, система Витуса всё равно не о том, насколько я понимаю.
Пнд 21 Янв 2013 22:22:17
Википедия - не в счет. Мы делаем движок для сайтов, где конфликты между авторами либо вообще не возникают (потому что править чужой текст нельзя), либо разрешаютя административным путём. 90% корпоративных wiki вполне этим ограничениям удовлетворяют.
Стремиться надо к тому, чтобы каждая операция редактирования изменяла ровно один первичный объект и ровно один файл в ФС. В нынешнем ТЗ есть ровно одно исключение — это разбитый на страницы список элементов с блоковым типом хранения, Там возможна ситуация, когда волна изменений покатится по всем страницам данного списка.
Потому что SSI обрабатывает HTML как поток байт. В эпоху utf-8 это недопустимо. И вообще, я категорически против любых инструментов, которые работают с html не как с DOM-деревом, и, следовательно, могут породить невалидный HTML. А средства, которые работают с DOM-деревом — медленные. А значит использовать какие бы то ни было преобразования html в момент отдачи недопустимо.
Вообще именно за это мне всегда хотелось поубивать нынешнюю команду ЖЖ. За то что у них происходит постинг коммента без перезагрузки страницы, а счетчик - не обновляется. Если ты не можешь гарантировать консистентность обновления счетчика, вообще не показывай счетчик.
Для крупных ресурсов она не настолько выгодна. Там скачки посещаемости более плавные, там есть деньги на нормального DBA и так далее. Поэтому можно не особенно зарекаться на масштабирование вверх. Так сразу и написать "если вы ожидаете более 2 комментариев в секунду, поищите другое решение". Я как раз хочу сделать решение для маленьких сайтов, где комментарий в две минуты это жуткий пик посещаемости. Потому что сейчас эти ресурсы невыгодно размещать на отдельных серверах. Они мрут как тольк ссылку запостят даже на слэшдот или ленту.вру, а даже в ЖЖ тысячника. Притом что из ста посетителей, пришедших по этой ссылке, хорошо если один соберется что-то откомментировать.
Пнд 21 Янв 2013 22:31:05
Что-то мне кажется, что SEO это такой эфемизм для слова "надувательство". Причем я никак не могу понять кто кого надувает - владелец сайта пользователей, или "оптимизаторы" владельца сайта.
А уж в блогах-то какое SEO? Половина пользователей ЖЖ вообще запрещает индексацию своих блогов поисковыми машинами. А Facebook совсем не индексируется.
Пнд 21 Янв 2013 22:50:27
Я тоже не люблю, когда врут. Поэтому наличия рядом со счётчиком слова "около", или "примерно", или "≈" меня вполне устроит. Дело ж не в том, что счётчик не точный, а в том, чтобы пользователи это понимали.
Втр 22 Янв 2013 08:20:25
Даже на самом небольшом wiki, если есть возможность редактирования без премодерации -- возможность откатить изменения необходима. Причем необходима возможность это сделать не только админу лично -- потому как у него может не быть времени заниматься сайтом настолько всерьез, чтобы оперативно реагировать.
Вот выложил я сайт и уехал в отпуск на месяц. Через месяц приезжаю -- а у меня там уже не wiki, а один сплошной рассадник спама и весь контент потерт, что я скажу цензурного? А при наличии хоть каких-то активных пользователей -- они сами быстро все пофиксят, а мне им останется только спасибо сказать (или если ресурс коммерческий -- ништяков каких-нибудь выдать в благдарность).
В этом смысле ваш wiki, это все-таки с точки зрения использования не wiki, а такая wiki-like CMS, с фактически единственным авторам. А я вот некоторое время активно развивал freesource.info, и реально если вкладываться в развитие community -- они там делают контента и правок куда больше чем я. И, кстати, главная претензия к тамошнему движку от юзеров -- невозможность удалять контент (ибо тамошний version control не умеет откатывать удаление -- потому оно всем кроме меня просто запрещено), и потому чтобы рассадники спама вычищать меня до сих пор зовут.
Важно не разрулить конфликт каким-либо путем -- административным, техническим, или хоть лицензией на отстрел спамеров, главное вернуть ценный контент на место, причем быстро, и желательно без необходимости вмешаться владельце сайта.
freesource.info, кстати, отнюдь не wikipedia (всего сотня-другая посетителей в день).
Другой практический пример -- мне вот очень хочется у себя на сайте сделать wiki по астериску. Очевидно что там обязательно будут и "кривые" правки, и спамеры, и прочий бардак. Хотя я и не расчитываю на более нескольких сотен посетителей в день.
"чтобы каждая операция редактирования изменяла ровно один первичный объект и ровно один файл в ФС" -- вот! Добавлю только что я хотел бы, чтобы "не менять другие объекты FS если в них содержатся первичные объекты" было MUST а не SHOULD.
Если вставляется код исключительно внутри тэгов (которые и так именуются в latin-1), то какие будут проблемы с utf-8? Я что-то пропустил, и в нем есть состояния передающиеся далее чем на следующий символ?
Операция вставки внутрь XML-файла блока, который также является валидным XML, если вставка происходит между тэгами (а не посередине тэга) не может породить невалидный XML, или я ошибаюсь? Причем если саму команду вставки рассматривать как тэг, то вставка внутрь валидного XML другого валидного XML безопасна.
Тут я не понимаю usecases где эта консистентность счетчика важна, кстати. Меня счетчик интересует до постинга, а не сразу после.
Ok, понял. Только уточню, что ресурс малой посещаемости может быть весьма объемным по контенту (по крайней мере тысячи первичных объектов, не считая комментариев). Поэтому полный лок на запись сайта при апдейте -- приемлемо, обновление всех html на сайте при посте одного коммента -- нет.
SEO бывает разное. Упрощенно -- черное, серое, белое.
Черное -- это прямая дурежка мозгов поисковой машине. За это ловят и банят. И это хорошо. Порядочному человеку заниматься этим бессмысленно.
Серое -- легальная дурежка поисковых машин. В реальном мире бывает нужно. Ровно по той же причине по которой нужно оружие -- в идеальном мире его вообще не должно быть, но в реальном у преступников оно есть, и честным людям обороняться надо. В основном это всякие штуки типа закупки ссылок и прочие небольшие трюки.
Белое -- демонстрация структуры данных и сайта поисковой машине так, чтобы она лучше их поняла, с учетом особенностей ее алгоритмов. Это и создание карты сайта (ныне обязательная вещь), и грамотная перелинковка, и прочие инструменты которые либо не мешают людям но помогают машинам, либо помогают и людям, и машинам лучше пользоваться сайтом.
Так вот -- блок 'related posts', например, помогает машинам, а также людям (они на него кликают! им интересно!), я как юзверь на заинтересовавших меня статьях также часто открываю ссылки related posts. Этот блок необходимо на любом блоге, автор которого хочет чтобы его читал неопределенный максимально большой круг лиц, и при этом читал в том числе старые посты.
ЖЖ и facebook используются разными людьми с совершенно разными целями. Среди которых как поделиться с друзьями фото своей кошки (чаще), так и активный обмен ценным контентом (реже). Для ценного контента его индексация и удобство навигации является ценнейшим преимуществом. И тут facebook, вконтактик и прочие ЖЖ даже рядом не стояли с тем же wordpress, это часто и вынуждает уходить на standalone, оставляя лишь плагины для публикации в facebook/vkontakte/ЖЖ или трансляцию.
Втр 22 Янв 2013 08:25:15
Ну и еще про SEO -- когда я пишу в блоге про свою жизнь, или очередную новость типа "собрал asterisk X.Y.Z в сизиф -- забирайте", индексация меня не интересует, и даже скорее вредна (было бы не лень -- научил бы wordpress запрещать индексацию таких страниц).
Если же я пишу, скажем, новый найденный мной рецепт для решения какой-то задачи в asterisk, или какой-нибудь линуксячий лайфхак -- я хочу чтобы желающие его таки нашли в гугле. А потом, если им это оказалось полезным, по ссылкам в посте нашли другие столь же полезные для них материалы.
По факту при установке wordpress (судя по различным статьям в сети) первым делом после его установки ставят разнообразные плагины для кэширования и ускорения (потому что он не тормоз -- он якорь), плагины для SEO, типа 'All in one SEO pack', и плагины для авторизации, публикации и комментирования через вконтактик и facebook.
Втр 22 Янв 2013 12:34:29
Типичная ниша для движка - это корпоративный или личный сайт-визитка, а не wiki. В этих случаях обычно за каждую рубрику или каждый материал есть ответственный человек.
Мы не делаем wiki, мы делаем именно CMS.
Я с крайним подохрением отношусь к идее "вики по какому-нибудь программному продукту". Сколько я за последнее время видет продуктов, у которых документация была в формате wiki, это значило что у них нет документации. Форум и то лучше. Кстати, вот форум - это нормальный usecase для stilllife, в отличе от wiki.
А вот это - невозможно. Вернее, противоречит всей идеологии. У нас вся дискуссия по посту будет содержаться в том же файле, что и сам пост. И пост, и каждый комментарий - первичные объекты.
Ну никого же не напрягает что кто-то выполняет update в базе данных sqlite, хотя это файл, в котором содержится дохрена первичных объектов. Не делайте идола из И FS. FS и DOM это такие деревья. И то и другое равно устойчиво к изменениям одного маленького фрагмента.
Операция вставки валлидного XML-блока - это абсолютно бессмысленная вещь для задачи "приделать общее оформление ко всем страницам сайта".
Как правило, это общее оформление требует, чтобы содержательный текст вставлялся как содержимое какого-то XML-элемента оформления, а не наоборот. А посколку URL, а значит и путь в ФС у нас адресует содержательный объект, SSI не решает задачи пределать к нему оформления, если мы не допускаем открытия тэгов в одном инклюде (верхнем), а зарытия в другом (нижнем).
Ну и записать сайт на сидюк становится невозможныМ.
С какой стати нам может потребоваться обновление всех html при апдейте? Сайт организован как дерево. И обновления пропагейтятся по этому дереву в основном снизу вверх, от листьев к корню.
То есть если не включать статистических счетчиков в общее оформление (а это следует явно запретить) то обновляться будет 3-4 файла,. Ну пусть десяток, если пользователь напихал в пост кучу тэгов.
Надо задуматься о специальном статусе тех объектов, которые включаются в общее меню, реплицируемое во все страницы Чтобы можно при их явном редактировании выдавать предупреждение "А вот сейчас у тебя на сайте все html-и перегенерироваться будут, ты уверен?".
А по моему опыту он машинам только мешает. Потому что в результате редкое слово, попавшее в загловок поста, вспывшего в этом блоке, начинает находиться на всех страницах сайта. Ссылки на тэг вполне достаточно.
Втр 22 Янв 2013 17:53:18
По поводу wiki vs форумы -- это уже скорее религия, тут мы похоже не договоримся. Я наоборот то с усмешкой, то с желанием кому-нибудь что-нибудь оторвать смотрю как пытаются реализовать де-факто wiki на форумном движке. Т.е. по сути -- есть "топик", который постоянно редактируют -- и дальше лента форума, которая по сути комменты к этому "wiki-страничке". А потом изобретают еще навигацию по этому счастью, и найти на таком форуме нужный контент превращается в квест.
Форум -- это обсуждение. wiki -- прекрасна в качестве конспекта результатов обсуждения. Wiki также прекрасен как сборник рецептов/HOWTO. Естественно, пытаться заменить полноценную документацию wiki это неправильно.
Главная суть wiki (с моей точки зрения) -- подмножество CMS, где возможно и поощряется не только создание контента посторонними, но и редактирование одной и той же единицы контента разными людьми, не связанными между собой какими-либо обязательствами, позволяющими применять административные меры. Единственное что принципиально отличает в этом смысле wiki от других CMS -- наличие простой к использованию VCS и крайняя простота перехода от режима просмотра к режиму редактирования. Причем второе это уже вопрос интерфейса, а не архитектуры.
Да, я не точно выразился. Но хотелось бы чтобы комментарии тут были единственным исключением.
А БД, в отличии от FS, имеет много классных средств вроде транзакций, и встроенного механизма блокировок, прозрачного для разработчика в большинстве простых случаев. Причем если мы говорим о PostgreSQL, то весьма умного механизма. Который повторно разрабатывать при использовании SQL уже не надо. А в системе на файлах -- надо. И чем она проще, тем лучше.
Не-не-не! Вы меня не так поняли! Я ни в коем случае не хочу видеть шаблонизатор на SSI -- у меня дома столько валерьянки не найдется чтобы потом в себя прийти после увиденного
Речь идет исключительно о вставке в шаблон законченных widget'ов. Вот есть, скажем, на каждой страничке блок с навигацией по датам, где отдельные числа -- ссылки на записи в блог за эту дату, часто встречается такой блок. Или тот самый блок "top 5 самых комментируемых постов недели".
Это полностью целостные объекты, каждый из которых представляет собой отдельный div с неким контентом. Вот их можно и вставлять, чтобы не генерировать.
Минус -- если записать сайт на сидюк без помощи wget'а, то этот сайт просто окажется без этих самых widget'ов. IMHO это уже не существенно.
Тут даже не запрет на статистику, а запрет включать в документы содержащие первичный контент генерат, базирующийся на другом первичном контенте. Напомню про мои любимые related posts. То есть включать-то можно, но только если обновление делается по cron, а не при каждом обновлении.
Кстати о меню. Вот тут как раз вариант с перегенерацией отдельно от добавления/редактирования объекта очень напрашивается. Если я решил выложить десяток новых страничек заготовленных, то не надо 10 раз перегенерировать весь блог. Достаточно перегенерировать его 1 раз по моему пинку (или, если я забыл пнуть -- по крону).
И, опять же, вот как раз такие объекты прямо напрашиваются на использование SSI.
Как такое могло получиться? Если related posts это ссылки, но наоборот все поисковики увидев слово в ссылке понимают, что это ценное слово для target'а этой ссылки. Вся раскрутка ссылками на этом построена. Если же related posts это plain text рядом с которым ссылка, типа "супер-пупер тема, смотри <a href="">сюда<\/a>", то это полная SEO-безграмотность разработчика сайта.
Втр 22 Янв 2013 18:22:52
Просто есть разные веб-сайты с разными задачами. Я не считаю возможным разработать универсальное решение, пригодное для всего. Вики-движков, хороших и разных, полно. В том числе и использующих version control-системы в качестве бэкэнда хранения. А я хочу заниматься областью, в которой vcs излишни.
Я не понимаю, что такое widget на web-сайте. widget-ы это по-моему из области UI десктопных программ. А весь проект нацелен на то, чтобы опровергнуть идею "сайт это программа". Потому что к программе нужны программисты. Кстати, если уж мы ограничиваем включаемые элементы прямоугольной областью, то зачем это делать server-side? Есть же iframe. Который будет прекрасно работать и на сидюке.
А мне бы хотелось, чтобы исключений вообще не было. Если уж без исключений нельзя обойтись, то исключения должны быть только негативными - такую-то комбинацию возможностей использовать нельзя потому что она оказывается излишне тяжелой. А все позитивные возможности должны быть правилами, которые комбинируются и образуют морфолоогический ящик, порождая комбинаторный взрыв возможностей.
БД это такой же код, написаный на таком же языке программирования. Не следует думать что вот его какие-то особо крутые гуру писали. А даже если и писали, никто не мешает взять и почитать. Мы планируем сделать тиражируемое решение. Поэтому клонировать концепции желательно не посредством code reuse, а посредством пропускания их через голову и реимплементации. Хотя, конечно есть несколько вещей, где я готов пойти на code reuse. Например, реализацию парсинга-работы с DOM-сериализации взять готовую.
По-моему это избыточно жесткое условие. Можно его смягчить. Нужно не допускать общий декор таких элементов, которые могут измениться не в результате явного редактирования. То есть, чтобы берясь редактировать название раздела, пользователь четко осознавал, что он меняет нечто, что будет видно на всех страницах сайта. Но чтобы "невинное" действие вроде постинга комментария где-то в рубрике третьего уровня не могло привести к изменению станрдартного оформления сайта.
То есть я бы исходил из того, что документ, не содержащий первичного контента у нас исключение, а не правило. А любой "генерат" базируется на другом первичном контенте.
Втр 22 Янв 2013 20:08:00
То есть игнор vcs это осознанное решение, Ok.
Widget на сайте -- некий отдельный логический блок, отображающий некую информацию. Расскажу как это в Wordpress выглядит:
Подразумевается что каждая "тема" имеет несколько мест, где такие объекты могут размещаться, например правая/левая колонка, заголовок, подвал (каждый из них может быть разделен на зоны), эти области выделяются еще на этапе верстки темы.
Сам widget это некий код, который выдает на выход HTML, который вставляется в одну из этих зон. Это делается прямо в админке. Примеры таких блоков -- related posts, recent comments, форма авторизации, кнопки репоста, облако тэгов, календарь, кнопка подписки на RSS, просто список страниц, баннер, или что угодно еще.
У wordpress на оптимизацию производительности забили болт, потому в одну кучу смешаны как явно статичные вещи, так и динамические разной логики -- по любому там при прорисовке выполняется код для всех widget'ов.
В общем это произвольный блок с чем-то. Подавляющее большинство таких блоков в вашей идеологии могут быть и полностью статическими, некоторая часть потребует обновлений части страниц при обновлении стороннего контента, но некоторая (например recent comments, или та же статистика) требует перегенерации всех страниц при каждом обновлении чего-либо.
По iframe -- ой не люблю я его. Для контента который должен видеть только человек, а роботы не должны -- уж лучше подгрузка с помощью js, это еще и гибче. А вот для контента, который хочется скормить и роботам тоже iframe уже не катит точно также как и js. Т.е. для recent comments -- пущай будет js, а вот для related posts нужен чистый html (но с ним, как я говорил, можно делать обновление не по изменению объекта, а по пинку).
В общем признаю, примеры widget'ов где обязательно чистый html, и при этом нужно обновление на каждый чих а не по крону придумать не могу. И, наверное, не смогу -- то что обновляется (а не добавляется) очень часто поисковым машинам не интересно.
Про комбинаторный взрыв возможностей -- логично, согласен.
Я не про code reuse, я про то, что выбранная архитектура отражается на размере code base, а следовательно сложности как написания, так и сопровождения, в том числе сопровождение администраторами инсталляций.
Т.е., условно, речь о том что "первичный контент" бывает разных видов, в т.ч. отличающихся вероятной частотой обновления. Ссылки на то, что меняется редко безопасны, ссылки на то, что меняется часто -- недопустимы. Понятия "редко" и "часто" не определены, но любой контент оставляемый сторонними пользователями (не владельцем ресурса) стоит считать, условно, "часто" обновляемым.