XML и комментарии

15 апреля 2009 года, 20:57

Web-разработчики придумывают множество интересных вещей, которые находят применение в самых различных областях деятельности в сети. Самое интересное, что довольно часто изобретённые технологии применяют не там, где ожидали разработчики, однако, это тоже приносит свои плоды. Неординарность применения разработок — это один из ключей к изобретению новых подходов обработки, хранения и передачи данных.

Комментирование

Форма комментирования (да и любая другая форма ввода) является одним из самых интересных, но в то же время сложных компонентов сайта. Чего только стоит соблюдение разметки комментария, ведь большинство сайтов позволяют так или иначе выделять определённые части введённого ими текста. Некоторые в качестве языка разметки комментария предпочитают (X)HTML, чему радуются Web-разработчики, другие — более приспособленные к полевым условиям движки: Markdown, Textile, BBCode и многие-многие другие. Мы остановимся на близкой сердцу разработчика XHTML-разметке, потому что она более природна, органично вписывается в интерьер Web-среды и позволяет держать написанный текст под контролем, а это самое главное тогда, когда предоставляется форма комментирования.

Как держать под контролем?

Для того, чтобы авторы комментариев успешно могли применять (X)HTML-комментарии, а администраторы сайтов чувствовали себя под защитой от разного рода нападений, можно использовать два подхода, один из который будет критическим, а второй — упрощённым, но от этого менее прочным.

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

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

  1. Высокая нагрузка является основным недостатком подобного подхода, так как обработка входящих данных в качестве XML — это не самая тривиальная задача. Разумеется, существуют очень быстрые парсеры, которые способны мгновенно обрабатывать данные размером от 10 мегабайт, однако это единичные измерения, которые в большинстве случаев неприменимы в высоконагрузочных системах. С другой стороны, если удачно справиться с кешированием данных (то есть не обрабатывать каждый раз пришедшие куски данных вновь и вновь, а кешировать обработанные куски, обрабатывая лишь новые данные), то нагрузка может быть незначительно снижена;
  2. Проверки подобного рода — они как игрушки: подходят для одного сайта, но не подходят для другого. К примеру, в блоге Web-разработчика поиграться с мини-валидатором довольно приятно, особенно, если его внешний вид будет напоминать старшего брата. Это придаёт стиль блогу, явную тематическую окраску и направленность. Однако для других тематических блогов такая проверка может быть избыточной.

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

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

К упрощённому подходу подходят ошибки и критического подхода, кроме второго, и добавляются некоторые нюансы, ведь исправление ошибок — это не совсем простая деятельность, она также сопряжена с определёнными трудностями.

Выводы

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

Мнения (10)

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

  • Илья

    16 апреля 2009 г.02:27

    Количество тегов которые реально будут использоваться при комментировании не так уж и велико, ведь так? Почему же тогда их не ограничить, это поможет снизить кол-во проверок, тем самым будет выигрыш во времени.. Ограничив теги можно (и нужно) сделать wysiwyg, чтобы и рядовой пользователь смог оформлять комментарий достойно. Таким образом ограничив кол-во тегов, предусмотрев конкретно их вложенность, и стандартные стили можно добиться

    • Создания более-менее универсального редактора
    • Валидного кода на выходе
    • Радость как и веб-разработчика так и обычного пользователя
  • Дин автор

    16 апреля 2009 г.10:33

    @Илья, вполне подходящее развитие событий, однако я говорил о разметке без визуальных редакторов, то есть о чистой XHTML-разметке. Ваша идея, конечно, хороша.

  • Arwy

    16 апреля 2009 г.13:26

    Мне кажется, что формы комментариев должны быть приспособлены как для самых простых и неискушённых, так и для более опытных пользователей. Если комментирует человек, который не знает всяких html-тегов, то сделать так, чтобы ссылка в виде текста становилась кликабельной, например. Если человек знает теги, дать возможность их использовать. Желательно ещё, чтобы была возможность где-нибдь на сайте прочитать, какие теги разрешено использовать: можно ли вставить картинку, как вставлять ссылки и так далее, а то на разных ресурсах дела с этим обстоят по-разному. Бывает обидно, когда пишешь длинный комментарий, пытаешься правильно оформить свою мысль, потом расставить теги, вставляешь ссылки или картинки, а их не видно. Я за это не люблю такой популярный Intense Debate, который везде, где только можно, прикрутили. Специально на их сайте искала, с какими тегаи он дружит, а с какими нет — так и не нашла. Ссылки тоже нормально оформить не даёт. Мне с ним после Хабра трудно.

  • Barttos

    06 мая 2009 г.21:21

    Мне из последних что видел запомнился редактор http://trashbox.ru/-а. Кто хочет может попробовать.

  • tenshi

    08 мая 2009 г.22:43

    без визивига хтмл идёт лесом, ибо гемор. лучше маркдаун в таких условиях.

  • Дин автор

    08 мая 2009 г.23:26

    @Tenshi, о вкусах не спорят. Кому-то хочется визуально оформлять текст сразу, кому-то хочется с нуля писать XHTML-разметку. Тут нет определённой истины, о которой можно говорить с такой уверенностью.

  • Scratch613

    11 июня 2009 г.20:38

    Создаем подмножество XHTML специально для комментариев, со своим DTD? :)

  • Дин автор

    12 июня 2009 г.15:07

    @Scratch613, крайняя мера. ;-)

  • Рюмкин

    18 марта 2010 г.03:02

    Тоже бился с этой проблемой в PHP. Были найдены варианты: - Использовать XML-парсер объекта DOMDocument, но он не указывает место ошибки, следовательно, в большом тексте пользователю придётся долго копаться самостоятельно. — Использовать xml_parse, и в полу-ручном режиме перебирать теги, он указывает точное место ошибки, но в байтах, что при использовании русских букв и кодировки utf-8 даёт значительный «промах» при детектировании места ошибки и вылетает при конструкциях типа « (нужно переводить в юникод). - Написание собственного простого парсера, который анализирует синтаксис и пропускает, но не валидирует DTD и namespaces , из минусов: низкая скорость по отношению к встроенным парсерам. (собственно этот метод был реализован) — Написание собственного парсера в виде модуля к PHP. Минус — знание Си, невозможность использовать на большинстве хостигов.

  • Рюмкин

    18 марта 2010 г.03:03

    P.S. Не вник в разметку

Я тоже знаю!

Для обращения к человеку используйте символ @, после которого следует имя того, к кому обращаетесь (пробелы заменяются на знак подчёркивания). Если вам интересно, можете подписаться на комментарии по RSS или по эл. почте. Ведите себя достойно, вы же не роботы, правда?

Вы можете использовать следующие XHTML-элементы в разметке комментария: strong, em, span[class=crossline], a[href=uri], code[type=язык], blockquote, ul и ol. В качестве языка кода может быть указан, например, javascript или css.