Web-разработчики придумывают множество интересных вещей, которые находят применение в самых различных областях деятельности в сети. Самое интересное, что довольно часто изобретённые технологии применяют не там, где ожидали разработчики, однако, это тоже приносит свои плоды. Неординарность применения разработок — это один из ключей к изобретению новых подходов обработки, хранения и передачи данных.
Комментирование
Форма комментирования (да и любая другая форма ввода) является одним из самых интересных, но в то же время сложных компонентов сайта. Чего только стоит соблюдение разметки комментария, ведь большинство сайтов позволяют так или иначе выделять определённые части введённого ими текста. Некоторые в качестве языка разметки комментария предпочитают (X)HTML, чему радуются Web-разработчики, другие — более приспособленные к полевым условиям движки: Markdown, Textile, BBCode и многие-многие другие. Мы остановимся на близкой сердцу разработчика XHTML-разметке, потому что она более природна, органично вписывается в интерьер Web-среды и позволяет держать написанный текст под контролем, а это самое главное тогда, когда предоставляется форма комментирования.
Как держать под контролем?
Для того, чтобы авторы комментариев успешно могли применять (X)HTML-комментарии, а администраторы сайтов чувствовали себя под защитой от разного рода нападений, можно использовать два подхода, один из который будет критическим, а второй — упрощённым, но от этого менее прочным.
Критический подход обработки комментариев состоит в том, что мы должны проверить, валидным ли является комментарий. Если это условие подтверждается, мы спокойно отправляем комментарий в дальнейшее плавание. С другой стороны, если при валидации были обнаружены ошибки, то следует сообщить о них автору комментария и попросить его их исправить.
Такой подход заставит задуматься тех, кто неверно оформляет собственные комментарии: неправильно вкладывает элементы друг в друга или пытается с помощью атрибутов самых распространённых элементов найти разнообразные уязвимости в системе обработки комментариев. Такие пользователи должны быть предупреждены о том, что их комментарий невозможно обработать и им следует изменить его. Так как проверка является достаточно строгой, то риск проникновения в систему снижается до минимального. То же самое, к слову, можно делать и со статьями в коллективных блогах, дабы предотвратить те же самые ошибки. К сожалению, у критического подхода есть и отрицательные стороны:
- Высокая нагрузка является основным недостатком подобного подхода, так как обработка входящих данных в качестве XML — это не самая тривиальная задача. Разумеется, существуют очень быстрые парсеры, которые способны мгновенно обрабатывать данные размером от 10 мегабайт, однако это единичные измерения, которые в большинстве случаев неприменимы в высоконагрузочных системах. С другой стороны, если удачно справиться с кешированием данных (то есть не обрабатывать каждый раз пришедшие куски данных вновь и вновь, а кешировать обработанные куски, обрабатывая лишь новые данные), то нагрузка может быть незначительно снижена;
- Проверки подобного рода — они как игрушки: подходят для одного сайта, но не подходят для другого. К примеру, в блоге Web-разработчика поиграться с мини-валидатором довольно приятно, особенно, если его внешний вид будет напоминать старшего брата. Это придаёт стиль блогу, явную тематическую окраску и направленность. Однако для других тематических блогов такая проверка может быть избыточной.
В целом, если такую систему использовать на ненагруженных ресурсах (тематические персональные блоги, как вариант), то она не должна показывать свои плохие качества, а служить верой и правдой администратору. К тому же, последний может собирать статистику, какие ошибки люди больше всего совершают в (X)HTML-разметке и радовать читателей полезными сведениями.
Упрощённый подход, в целом, аналогичен критическому, за исключением того, что он работает по исправляющей схеме, а не по оповещающей. Это означает, что если автор комментария допустил какие-либо ошибки в своём творении, система сама будет стараться их исправить, нежели сообщать об этом автору. Она также будет пытаться обнаружить попытки проникновения и автоматически обезопасить систему.
К упрощённому подходу подходят ошибки и критического подхода, кроме второго, и добавляются некоторые нюансы, ведь исправление ошибок — это не совсем простая деятельность, она также сопряжена с определёнными трудностями.
Выводы
Разумеется, все эти рассуждения являются не более чем плодом больного воображения автора, хотя, кто знает, возможно, при довольно серьёзной оптимизации, они найдут своё место под солнцем будущих проектов.
