vitus: comment 4

vitus
Sun, 20 Jan 2013 13:16:49 +0400

XML -- зло. А уж XSLT -- тем более. Людей которые умеют этим нормально пользоваться можно пересчитать по пальцам.

Главное, что XML/SGML - единственное, что умеют понимать браузеры.

Вообще в идее, что плагины писать сложно, что-то есть. У пользователя не должно возникать желания сразу бросаться писать плагины. Он должен сначала немножко подумать, а нельзя ли решить задачу без них. 99% задач, которые действительно стоит решать, решаются либо в рамках предложенного DSL, либо с помощью внешних сервисов, интегрированных в сайт.

Для темлпейтов есть прекрасные темплейтные движки -- CTPP прекрасен своим плагином для nginx, который умеет получать от скрипта JSON, а потом из этого JSON и темплейта генерировать уже что душе угодно. Ну и он действительно быстрый.

Предложенная система в бесконечное число раз быстрее любого вашего плагина, потому что она НЕ ВЫПОЛНЯЕТ НИКАКИХ ПРЕОБРАЗОВАНИЙ над контентом, отдавая его пользователю.

У нас 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, мы об этом поговорим. И то вряд ли что получится, потому что пользователь хочет красивого дизайна. При отображении в браузее MarkDown это вряд ли получится.

В качестве формата для хранения различных метаданных -- JSON.

Невизуализруемые данные в этой системе - исключение (пароли, если они есть, email-ы уже под вопросом, может их лучше и показывать). И для их хранения не нужен никакой структурированный формат. Проще каждый атрибут в отдельной dbm хранить.

Любые эзотерические технологии имеет смысл использовать только если они дают какие-то killer features. XSLT сейчас можно считать эзотерической технологией.

XSLT это yet another язык. Хорош тем, что он непроцедурный. Плох тем, что предъявляет серьезные ограничения к формату входных данных. Если мы выдаем данные в таком виде, что их поймет ДАЖЕ XSLT, любой другой язык их тем более поймет.