Ни о чём →
McDao – MarkDown с акцентом
Вопрос о методике контент менеджемента (в узком техническом его смысле, как конкретно редактор контента управляет данными) передо мной стоял уже давно. Многолетний опыт разработок показал, что однозначного ответа нет и не будет. Очень много зависимостей от конкретной задачи, технический подготовке менджеров и других факторов. Решение о том, какая методика будет применена в системе, будет разная в каждом случае.
Но по крайней мере удалось выявить кое-какие однозначные элементы. Например несокрушимой истиной встал тезис: «WYSIWIG – абсолютное зло». Здесь имеется в виду WYSIWIG редакторы общего назначения, как TinyMCE и ему подобные. Ниже мы коснемся «ограничивающих» редакторов как одно из допустимых зол.
В чем основная проблема с WYSIWIG? Никто и никогда не заставит редактора придерживаться разработанного единого стиля сайта. Он(а) всегда найдет оправдание для себя, почему здесь фон ядовито желтый, а там заголовок розовый. Это по большеому счету не проблема, пусть владелец сайта наслаждается своим творчеством. Проблема начинается, когда поступает команда обновить дизайн всего сайта. Шапки, менюшки, подвал мы конечно поменяем, но что делать с контентом? Даже если бы сферический менеджер в вакуме строго придерживался рекомендаций дизайнера, то все равно об HTML код, порожденный WYSIWIG редактором, поломается немало зубов.
Как один из выходов можно применить специальные WYSIWIG редакторы, где обрезаны практически все возможности за исключение тех стилей, которые предусмотрел дизайнер в данном проекте. Соответственно и HTML код будет порождаться вполне «чистый». Такое решение например применимо, когда потенциальный редакторский контингент неисправимо блондинист.
Однако даже «ограничивающие» WYSIWIG редакторы не являются идеальным вариантом. Причин для этого по крайней мере две. Во-первых не все элементы контента удается заWYSIWIGить. То там, то тут приходится расставлять условные маркеры для вставки гаджетов и других нестандартных элементов. В некоторых проектах их так много, что возникает вопрос: «За что боролись? Не проще ли тогда весь контент размечать?»
Вторая причина для неиспользования даже «ограничивающих» WYSIWIG в том, что к ним приходится дописывать кучу кода в виде менеджеров картинок, стилей, гаджетов и пр. Причем даже если кажется, что все предусмотрено, оказывается, что чего-то нехватает или работает неудобно, или не так, как нам надо в данном проекте. Что мы делаем по сути? Мы создаем неудобные угловатые велосипеды, заменяющие старые, всем известные привычные файл-менеджеры, браузеры и другие элементы операционной системы.
Попытаемся уменьшить количество степеней свободы. Допустим, что менеджеры у нас компьютерно грамотные люди. Они знают, что такое файл, что такое вебстраница с ее адресом, умеют отличить картинку на свем диске от картинки в интернете. Таких держать на коротком поводке WYSIWIGов с их убогими средствами себе дороже. Им нужно предоставить удобную и немногословную систему маркировки и отпустить в свободное плавание.
Выбор маркировки на самом деле не велик. HTML однозначно отпадает. Причем не из-за какой-то мифической «опасности» (во-первых, отфильтровать его не составляет труда в наши дни, а во-вторых, зачем вообще фильтровать ввод от модератора/менеджера/владельца сайта). Основная причина в том, что в HTML слишком многословен. Например чтобы создать такой очень типичный элемент, как картинка с подисью, надо написать порядочную кучку кода. Заставлять такое делать менеджеров даже копипастом не совсем корректно. Можно расширить HTML стандарт для данного конкретного проекта и внести дополнительные теги и атрибуты. Но в целом все это выглядит очень неопрятно.
Вторая альтернатива – BB-коды. По сути это и есть то самое расширение HTML, о котором сказано в предыдущем абзаце. А по сему неопрятность остается. Кроме этого нелаконичность. Текст с BB-кодами читается очень трудно. Возможно из-за того, что квадратные скобки слишком хорошо сливаются с буквами, в отличие скажем от тех же угловых скобок. WYSIWIG редакторы, генерирующие BB-коды, я считаю чьей-то неудачной шуткой.
Наконец-то мы добрались к сути статьи. Да, тот последний вариант MarkDown. В целом MarkDown создает хорошее впечатление. Он лаконичен, мнемоничен, хорошо воспринимается визуально. Есть некоторые недостатки, такие как ограниченность лексики и разнобой в диалектах. Собственно эти вопросы и предназначен решить McDao.
McDao (произносится «мэкдао») это библиотека-парсер разметки в стиле MarkDown, написанная на PHP и предназначенная для встраивания в системы управления контентом. Главной особенностью McDao является расшираемость. Можно вводить свои маркеры из любых символов или их комбинаций, а также переопределять стандартные маркеры. Кроме этого введен унифицированный синтаксис детализации маркеров. Это в первую очередь касается таких более сложных элементов как картинки или ссылки. От википедевской какофинии скобок немного подташнивает. Редактору википедии на полставки нет проблем, но для любого другого мирянина эти груды скобок ну ни разу мнемоничны.
Этот синтаксис детализации также применим к любому другому стандартному или доопределенному маркеру, не только к ссылкм и картинкам. Я не утверждаю, что этот синтаксис является образцом мнемоничности, но тем не менее он хорош тем, что совместим со всеми маркерами, и как вы убедитесь далее совсем не экзотичен.
McDao подразумевает две сущности: абзац, отделенный от другого как минимум одной пустой строкой, и внутристрочный текст. Собственно тут ничего нового, мы просто констатируем это правило. Первый неалфавитноцифровой символ (или несколько символов), отделенные от остального текста пробелом, явлется управляющим для данного абзаца. Про внутристрочный текст ничего особенного писать не надо, все прекрасно знакомы с его использованием. Все это можно проиллюстрировать так:
Знакомо, не правда ли? Теперь о более тонком вопросе – квадратных скобках. По умолчанию мы отдали их всецело только картинкам [picture.jpg]. А что же досталось ссылкам? Ни за что не догадаетесь: _www.example.com_. А как же обычное подчеркивание? Ну во-первых, в хорошем стильном и практичном дизайне обычному подчеркиванию места нет. А во-вторых, если парсер посчитает, что ему попалась не ссылка, то он этот текст подчеркнет.
Теперь само зерно диалекта McDao, как мы вводим дополнительные атрибуты к маркерам. Для этого используются угловые скобки так: [картинка]<picture.jpg> и вот так: _пример_<www.example.com>. Почему именно так распределены данные? Мы пользуемся следующим правилом и рекомендуем вам, когда вы будете определять свои пользовательские маркеры: все что зритель видит (или потенциально видит) пишется внутри маркера, а технические «закадровые» атрибуты помещаются в угловые скобки. Формально, пользуясь этим правилом, если вы не задаете атрибут ALT для картинки, то надо писать [ ]<picture.jpg>. Да, можно и так. Но зачем же буквоедствовать там, где это необязательно, и где парсер прекрасно разберется с [picture.jpg]. Мы же изначально поставили себе целью лаконичность и дружелюбность синтаксиса.
Теперь более сложный пример: картинка с ссылкой. Правильно подсказывают из второго ряда, надо использовать _[ ]_. Однако дополнительных атрибутов набегает довольно много. Один из вариант с ними разобраться:
Но согласитесь, довольно неуклюже. Не лучше ли просто определить новый специальный маркер из двух символов, что мы и сделали:
Как вы заметили, если дополнительных атрибутов больше одного, то их надо поименовать.
Ни один здравомыслящий разработчик не позволит указывать абсолютные адреса на внутренние страницы сайта. И даже что-то типа
неприемлемо, поскольку может возникнуть ЧПУ и еще много чего. Вот тут нам и приходит на помощь перехват маркеров. Внутренний адрес можно писать в любом обусловленном синтаксисе, который будет разобран и на его место подставят то, что нужно. Например:
Для каких-то гаджетов можно определить специальные маркеры. Например нам надо вставить видео. Выбираем для видео маркер фигурных скобок. Получается как-то так: {j76JvlLbki45c}. Все некрасивые длиноты и полный путь к ютюбу спрятаны от менеджера контента заботливым разработчиком.
А еще нам надо на странице вставлять блоки текста или модули. Типа include… Что бы нам такое мнемоническое придумать? Ну пусть например запись, что здесь будет модуль новостей выглядит так: {+news+}. Не смущайтесь, что фигурные скобки уже задействованы под видео, все корректно обработается. Хотя надо заметить, в таком случае видео лучше было бы опредилить как нибудь типа {[video.flv]} мнемоничности и последовательности ради.
Аналогично все работает и с маркерами абзацев:
McDao позволяет создавать довольно сложные переопределения. Вот одна из типичных задач: определить список статей. Элементом списка являются: заголовок, ссылка, иконка, вступительный текст (teaser). Вот как справился с этой задачей McDao (после задания нескольких дополнительных правил):
Как вы видите, мы ввели специальный маркер «--» для определения элемента нашего расширенного списка. А все остальные определения вполне легко читаемы и очевидны.
Стандартное поведение по умолчанию McDao обеспечивает для следующих маркеров:
Предопределенные (но переопределяемые) внутристрочные маркеры:
Я не буду вдаваться в технические детали о том, как пользоваться данной библиотекой. Кого она заинтерсует сможет ее загрузить и разобраться. В целом библиотека довольно легковесна. Однако кеширование результатов ее работы никому еще не помешали (кеширование не входит в сферу McDao и возлагается на CMS).
Нельзя не отметить еще одну неожиданную сторону применения McDao. В одном из наших проектов понадобилось хранить и периодически редактировать данные довольно сложной структуры. Формально наиболее подходящим для этого считается XML. Однако сей уважаемый синтаксис, разрабатываемый как человекочитаемый, на деле оказался слишком многословным и очень нечитаемым. В принципе есть много более приятный YAML. Однако оказалось, что для этой цели можно задействовать McDao (с набором переопределенных правил). Это даже дало некоторые преимущества. Во-первых, менеджеры уже хорошо знакомы с его синтаксисом, а во-вторых, мнемоничность, разработанная специально для конкретной задачи, дала фору даже удобству YAML.
Таковым является McDao, который несомненно вызовет интерес ценителей MarkDawn'а и тех, кто ищет удобное решение в контент менеджменте, там где нужна практически неограниченная гибкость в сочетании с лаконичностью и простотой.
Но по крайней мере удалось выявить кое-какие однозначные элементы. Например несокрушимой истиной встал тезис: «WYSIWIG – абсолютное зло». Здесь имеется в виду WYSIWIG редакторы общего назначения, как TinyMCE и ему подобные. Ниже мы коснемся «ограничивающих» редакторов как одно из допустимых зол.
В чем основная проблема с WYSIWIG? Никто и никогда не заставит редактора придерживаться разработанного единого стиля сайта. Он(а) всегда найдет оправдание для себя, почему здесь фон ядовито желтый, а там заголовок розовый. Это по большеому счету не проблема, пусть владелец сайта наслаждается своим творчеством. Проблема начинается, когда поступает команда обновить дизайн всего сайта. Шапки, менюшки, подвал мы конечно поменяем, но что делать с контентом? Даже если бы сферический менеджер в вакуме строго придерживался рекомендаций дизайнера, то все равно об HTML код, порожденный WYSIWIG редактором, поломается немало зубов.
Как один из выходов можно применить специальные WYSIWIG редакторы, где обрезаны практически все возможности за исключение тех стилей, которые предусмотрел дизайнер в данном проекте. Соответственно и HTML код будет порождаться вполне «чистый». Такое решение например применимо, когда потенциальный редакторский контингент неисправимо блондинист.
Однако даже «ограничивающие» WYSIWIG редакторы не являются идеальным вариантом. Причин для этого по крайней мере две. Во-первых не все элементы контента удается заWYSIWIGить. То там, то тут приходится расставлять условные маркеры для вставки гаджетов и других нестандартных элементов. В некоторых проектах их так много, что возникает вопрос: «За что боролись? Не проще ли тогда весь контент размечать?»
Вторая причина для неиспользования даже «ограничивающих» WYSIWIG в том, что к ним приходится дописывать кучу кода в виде менеджеров картинок, стилей, гаджетов и пр. Причем даже если кажется, что все предусмотрено, оказывается, что чего-то нехватает или работает неудобно, или не так, как нам надо в данном проекте. Что мы делаем по сути? Мы создаем неудобные угловатые велосипеды, заменяющие старые, всем известные привычные файл-менеджеры, браузеры и другие элементы операционной системы.
Попытаемся уменьшить количество степеней свободы. Допустим, что менеджеры у нас компьютерно грамотные люди. Они знают, что такое файл, что такое вебстраница с ее адресом, умеют отличить картинку на свем диске от картинки в интернете. Таких держать на коротком поводке WYSIWIGов с их убогими средствами себе дороже. Им нужно предоставить удобную и немногословную систему маркировки и отпустить в свободное плавание.
Выбор маркировки на самом деле не велик. HTML однозначно отпадает. Причем не из-за какой-то мифической «опасности» (во-первых, отфильтровать его не составляет труда в наши дни, а во-вторых, зачем вообще фильтровать ввод от модератора/менеджера/владельца сайта). Основная причина в том, что в HTML слишком многословен. Например чтобы создать такой очень типичный элемент, как картинка с подисью, надо написать порядочную кучку кода. Заставлять такое делать менеджеров даже копипастом не совсем корректно. Можно расширить HTML стандарт для данного конкретного проекта и внести дополнительные теги и атрибуты. Но в целом все это выглядит очень неопрятно.
Вторая альтернатива – BB-коды. По сути это и есть то самое расширение HTML, о котором сказано в предыдущем абзаце. А по сему неопрятность остается. Кроме этого нелаконичность. Текст с BB-кодами читается очень трудно. Возможно из-за того, что квадратные скобки слишком хорошо сливаются с буквами, в отличие скажем от тех же угловых скобок. WYSIWIG редакторы, генерирующие BB-коды, я считаю чьей-то неудачной шуткой.
Наконец-то мы добрались к сути статьи. Да, тот последний вариант MarkDown. В целом MarkDown создает хорошее впечатление. Он лаконичен, мнемоничен, хорошо воспринимается визуально. Есть некоторые недостатки, такие как ограниченность лексики и разнобой в диалектах. Собственно эти вопросы и предназначен решить McDao.
McDao (произносится «мэкдао») это библиотека-парсер разметки в стиле MarkDown, написанная на PHP и предназначенная для встраивания в системы управления контентом. Главной особенностью McDao является расшираемость. Можно вводить свои маркеры из любых символов или их комбинаций, а также переопределять стандартные маркеры. Кроме этого введен унифицированный синтаксис детализации маркеров. Это в первую очередь касается таких более сложных элементов как картинки или ссылки. От википедевской какофинии скобок немного подташнивает. Редактору википедии на полставки нет проблем, но для любого другого мирянина эти груды скобок ну ни разу мнемоничны.
Этот синтаксис детализации также применим к любому другому стандартному или доопределенному маркеру, не только к ссылкм и картинкам. Я не утверждаю, что этот синтаксис является образцом мнемоничности, но тем не менее он хорош тем, что совместим со всеми маркерами, и как вы убедитесь далее совсем не экзотичен.
McDao подразумевает две сущности: абзац, отделенный от другого как минимум одной пустой строкой, и внутристрочный текст. Собственно тут ничего нового, мы просто констатируем это правило. Первый неалфавитноцифровой символ (или несколько символов), отделенные от остального текста пробелом, явлется управляющим для данного абзаца. Про внутристрочный текст ничего особенного писать не надо, все прекрасно знакомы с его использованием. Все это можно проиллюстрировать так:
= Заголовок первого уровня =
== Заголовок второго уровня ==
Обычный абзац с *выделенным* текстом.
Знакомо, не правда ли? Теперь о более тонком вопросе – квадратных скобках. По умолчанию мы отдали их всецело только картинкам [picture.jpg]. А что же досталось ссылкам? Ни за что не догадаетесь: _www.example.com_. А как же обычное подчеркивание? Ну во-первых, в хорошем стильном и практичном дизайне обычному подчеркиванию места нет. А во-вторых, если парсер посчитает, что ему попалась не ссылка, то он этот текст подчеркнет.
Теперь само зерно диалекта McDao, как мы вводим дополнительные атрибуты к маркерам. Для этого используются угловые скобки так: [картинка]<picture.jpg> и вот так: _пример_<www.example.com>. Почему именно так распределены данные? Мы пользуемся следующим правилом и рекомендуем вам, когда вы будете определять свои пользовательские маркеры: все что зритель видит (или потенциально видит) пишется внутри маркера, а технические «закадровые» атрибуты помещаются в угловые скобки. Формально, пользуясь этим правилом, если вы не задаете атрибут ALT для картинки, то надо писать [ ]<picture.jpg>. Да, можно и так. Но зачем же буквоедствовать там, где это необязательно, и где парсер прекрасно разберется с [picture.jpg]. Мы же изначально поставили себе целью лаконичность и дружелюбность синтаксиса.
Теперь более сложный пример: картинка с ссылкой. Правильно подсказывают из второго ряда, надо использовать _[ ]_. Однако дополнительных атрибутов набегает довольно много. Один из вариант с ними разобраться:
_[alt текст]<picture.jpg>_<address>
Но согласитесь, довольно неуклюже. Не лучше ли просто определить новый специальный маркер из двух символов, что мы и сделали:
_[alt текст]_<src=picture.jpg href=http://address>
Как вы заметили, если дополнительных атрибутов больше одного, то их надо поименовать.
Ни один здравомыслящий разработчик не позволит указывать абсолютные адреса на внутренние страницы сайта. И даже что-то типа
_Связаться с нами_<index.php?page=contact>
неприемлемо, поскольку может возникнуть ЧПУ и еще много чего. Вот тут нам и приходит на помощь перехват маркеров. Внутренний адрес можно писать в любом обусловленном синтаксисе, который будет разобран и на его место подставят то, что нужно. Например:
_Связаться с нами_<contact>
_Прейскурант в алфавитном порядке_<price,alpha>
Для каких-то гаджетов можно определить специальные маркеры. Например нам надо вставить видео. Выбираем для видео маркер фигурных скобок. Получается как-то так: {j76JvlLbki45c}. Все некрасивые длиноты и полный путь к ютюбу спрятаны от менеджера контента заботливым разработчиком.
А еще нам надо на странице вставлять блоки текста или модули. Типа include… Что бы нам такое мнемоническое придумать? Ну пусть например запись, что здесь будет модуль новостей выглядит так: {+news+}. Не смущайтесь, что фигурные скобки уже задействованы под видео, все корректно обработается. Хотя надо заметить, в таком случае видео лучше было бы опредилить как нибудь типа {[video.flv]} мнемоничности и последовательности ради.
Аналогично все работает и с маркерами абзацев:
= Какой-то особенный заголовок<special>
Этому абзацу тоже назначен атрибут. Непонятно
зачем он может понадобиться, но синтаксис это
позволяет сделать.<foobar>
% На нашем сайте надо центрировать некоторые абзацы
и мы решили задействовавать для этого символ «поцентр».
Видео или картинку также можно расположить по центру:
% {j76JvlLbki45c}
McDao позволяет создавать довольно сложные переопределения. Вот одна из типичных задач: определить список статей. Элементом списка являются: заголовок, ссылка, иконка, вступительный текст (teaser). Вот как справился с этой задачей McDao (после задания нескольких дополнительных правил):
-- Заголовок 1 [icon1.gif]<link1>
Introduction text blah-blah-blah…
-- Заголовок 2 [icon2.gif]<link2>
Another introduction text blah-blah-blah…
Как вы видите, мы ввели специальный маркер «--» для определения элемента нашего расширенного списка. А все остальные определения вполне легко читаемы и очевидны.
Стандартное поведение по умолчанию McDao обеспечивает для следующих маркеров:
= Заголовок =
== До шести уровней ==
=== Закрывающий маркер необязателен
--- (горизонтальный разделитель)
- ненумерованный
- список
- элементов
# или нумерованный
# список
Предформатированный
текст начинается
с пробелов
> Цитата с одним символом «>» в начале
> или в каждой строке
|= Колонка1 =|= 2 =|= 3 =|
| Несложные | таблички | можно |
| нарисовать | символами | |
| | xxx | |
Абзац без всяких маркеров тоже можно перехватить и
обработать. По умолчанию он <p>ируется.
<script>
/* любой абзац, представляющий из себя HTML код, остается как есть */
</script>
Предопределенные (но переопределяемые) внутристрочные маркеры:
*выделение*
/курсив/
^верхний индекс^
_ссылка или подчеркивание_
[картинка]
_[картинка с ссылкой]_
Я не буду вдаваться в технические детали о том, как пользоваться данной библиотекой. Кого она заинтерсует сможет ее загрузить и разобраться. В целом библиотека довольно легковесна. Однако кеширование результатов ее работы никому еще не помешали (кеширование не входит в сферу McDao и возлагается на CMS).
Нельзя не отметить еще одну неожиданную сторону применения McDao. В одном из наших проектов понадобилось хранить и периодически редактировать данные довольно сложной структуры. Формально наиболее подходящим для этого считается XML. Однако сей уважаемый синтаксис, разрабатываемый как человекочитаемый, на деле оказался слишком многословным и очень нечитаемым. В принципе есть много более приятный YAML. Однако оказалось, что для этой цели можно задействовать McDao (с набором переопределенных правил). Это даже дало некоторые преимущества. Во-первых, менеджеры уже хорошо знакомы с его синтаксисом, а во-вторых, мнемоничность, разработанная специально для конкретной задачи, дала фору даже удобству YAML.
Таковым является McDao, который несомненно вызовет интерес ценителей MarkDawn'а и тех, кто ищет удобное решение в контент менеджменте, там где нужна практически неограниченная гибкость в сочетании с лаконичностью и простотой.
09.05.2011 12:43+0400