Цель. Сбор информации, обсуждение и подготовка обзорной статьи о парсинге сообщений в html-кодах и в bb-кодах.
Название статьи: "Принципы парсинга сообщений. Применение html-кодов и bb-кодов".
Аннотация. Принципы парсинга сообщений в блогах, комментариях и на форумах. Парсинг с применением html-кодов, достоинства и недостатки. Парсинг с применением bb-кодов, достоинства и недостатки. Преимущества парсинга при создании сообщений над парсингом при отображении сообщений (при генерации страницы с сообщением). Преимущества и недостатки хранения в БД текста сообщений, форматированного в bb-кодах и текста сообщений, форматированного в html-кодах. Возможность оптимизации форматирования текста в html-кодах за счет записи значений атрибутов html-тегов без кавычек.
Рассматриваемые вопросы
* Парсинг сообщений в bb-кодах.
* Хранение сообщений в БД с форматированием текста в bb-кодах.
* Парсинг сообщений в html-кодах
* Хранение сообщений в БД с форматированием текста в html-кодах.
* Возможности и ограничения оптимизации форматирования и парсинга текста в html-кодах за счет записи значений атрибутов html-тегов без кавычек.
Текущая ситуация. Проблемы и решения
На текущий момент форматирование и парсинг текста сообщений в блогах, комментариях, на форумах и т.д. в bb-кодах весьма популярно,. В частности, парсинг bb-кодов довольно хорошо отработан на форумном движке FluxBB последних версий. При этом в БД хранится текст сообщений, отформатированных в bb-кодах. Такой подход имеет ряд ограничений и недостатков. Например, необходимость парсить сообщения (преобразовывать из представления в bb-кодах в представление в html) при каждом просмотре сообщения. Это может довольно серьезно нагружать сервер хостера . В то же время, хранение в БД соощений, отформатированных в html-кодах, избавляет от необходимости парсить такие сообщения при их просмотре (отображении). Однако, парсинг таких сообщений при их создании и редактировании существенно сложеннее парсинга в bb-кодах. Кроме того, хранение в БД сообщений, отформатированных в html-кодах обладает ощутимой избыточностью, по сравнению с хранением в БД сообщений, отформатированных в bb-кодах. Определенным образом упростить операции с сообщениями в html-кодах может определение правил, по которым возможна запись значений атрибутов html-тегов, используемых для форматирования, без кавычек. При этом ощутимо упрощается парсинг таких сообщений. Но и, соответственно, появляются некоторые ограничения форматирования, поскольку запись значений атрибутов html-тегов без кавычек не всегда допустима. Насколько серьезны такие ограничения - предстоит выяснить при обсуждении темы. Мне представляется, что при грамотном подходе эти ограничения на 95% можно обойти, получая при этом доволльно мошный и богатые возможности форматирования текста сообщений в html-кодах. Со всеми преимуществами такого подхода.
PS. На этом форуме, как я наблюдаю, создание сообщений также происходит с форматированием в bb-кодах.
1. sadex - 04 Июля, 2013 - 10:09:35 - перейти к сообщению
2. avtor.fox - 04 Июля, 2013 - 10:13:24 - перейти к сообщению
щто?
пиар своего "форума разработчиков"?
пиар своего "форума разработчиков"?
3. sadex - 04 Июля, 2013 - 10:18:42 - перейти к сообщению
avtor.fox пишет:
щто?
пиар своего "форума разработчиков"?
пиар своего "форума разработчиков"?
А продуктивных мыслей нет? Нет никакого "форума разработчиков", есть обкатка движка в экстримальном режиме на бесплатном хостинге. И скоро этот движок оттуда будет снесен. И какой смысл пиарить то, чему суждено исчезнуть? Просто сейчас там в тестовом режиме обкатываются и определенные решения по парсингу, о которых говорится в теме. Т.е. кое-что можно посмотреть и пощупать руками в реальной работе. Остальное - в теме. Меня вопросы темы интересуют гораздо больше, чем ссылка на рабочий пример. Ссылку могу хоть сейчас убрать, если публике не нравится.
Насколько я понимаю, на этом форуме, также как и на FluxBB, в БД хранятся сообщения, пропарсенные при создании и отформатированные в bb-кодах. Значит, проблема аналогичная. При каждом просмотре таких сообщений не только участниками форума, но и любыми случайными посетителями, которых в десятки раз больше участников, такое сообщение надо доставать из БД, парсить его из представления в bb-кодах в html-представление, и генерировать страницу с сообщением уже в окончательном html-представлении. А это изърядная нагрузка на сервер при относительно плотной посещаемости форума.
4. avtor.fox - 04 Июля, 2013 - 10:27:24 - перейти к сообщению
sadex, Вы разводите воду-водную, а от меня требуете конструктивности (думаю, что Вы немного запутались в терминах)? Всё за Вас уже давно обдумано и решено.
5. sadex - 04 Июля, 2013 - 10:31:54 - перейти к сообщению
avtor.fox пишет:
Все - не может быть решено. Эта проблема продолжает обсуждаться на разных ресурсах, и единого мнения не сложилось. Кто-то отстаивает работу с bb-кодами, кто-то с html-кодами.Всё за Вас уже давно обдумано и решено.
По поводу возможности записи значений атрибутов html-тегов без кавычек - это тоже интересный вопрос. В HTML5 это вполне допускается. Часто это во многом упрощает работу парсера.
6. caballero - 04 Июля, 2013 - 10:41:48 - перейти к сообщению
хранение HTML в Бд как минимум будет занимать больше места.
вообще, когда я писал свой форум - такая мысль была но отказался от нее , к сожалению не помню почему.
вообще, когда я писал свой форум - такая мысль была но отказался от нее , к сожалению не помню почему.
7. sadex - 04 Июля, 2013 - 11:42:17 - перейти к сообщению
caballero пишет:
А насколько больше? Сам объем форматирования (в bb или в html) по отношению к объему текста не так уж и велик, имхо. Ну несколько увеличится объем форматирования в html по сравнению с объемом оного в bb - ничего страшного. На то она и БД, чтобы расплачиваться некоторым несущественным увеличением своего объема для создания удобства и увеличения скорости работы движка, плюс снижения нагрузки на сервер при отображении сообщений. Значительного снижения, поскольку сообщения, отформатированные и хранимые в БД в html представлении парсить при отображении практически не нужно.хранение HTML в Бд как минимум будет занимать больше места.
caballero пишет:
Точно не уверен, но вроде бы в SMF сообщения в БД хранятся с HTML-форматированием.
вообще, когда я писал свой форум - такая мысль была но отказался от нее, к сожалению не помню почему.
8. vanicon - 04 Июля, 2013 - 12:27:51 - перейти к сообщению
sadex
Скорость да наверное возрастет, но тут есть существенный минус, что если допустим поменяются какие-нибудь стили или разметка, то что делать будите, с разметкой которая в бд?
Скорость да наверное возрастет, но тут есть существенный минус, что если допустим поменяются какие-нибудь стили или разметка, то что делать будите, с разметкой которая в бд?
9. sadex - 04 Июля, 2013 - 13:30:56 - перейти к сообщению
vanicon пишет:
Встречный вопрос. Что будете делать в аналогичном случае, если форматирование текста сообщений хранится в БД в bb-кодах?если допустим поменяются какие-нибудь стили или разметка, то что делать будите, с разметкой которая в бд?
Сугубое имхо. Разметка отформатированного текста сообщений (кроме заголовков этих сообщений, которые подобным образом - через bb- или html-коды - вообще не форматируются) не имеет особого отношения к стилю самого сайта (блога, форума и т.д.).
Ведь эта разметка отдана на откуп юзеру, на его усмотрение. И потому она может быть совершенно любой. Свободу юзера при этом определяет или создатель сайта или админ, эта свобода зависит исключительно от состава опций панели инструментов формы редактирования сообщений. А состав этих опция для админов и модераторов может быть один (обширный) а для рядовых юзеров другой (минималоьтный, например только B, I, U, quote, code, url - без цветов).
Здесь состав таких опций для рядовых юзеров довольно богатый...
Вопрос - как повлияли мои упражнения со здешними довольно богатыми опциями bb-кодов для юзеров на общий стиль форума? Имхо - почти никак. Они повлияли только на стиль моего сообщения.
vanicon пишет:
Не только в скорости дело. Появляется возможность исключить процедуру (довольно затратную по ресурсам сервера) парсинга сообщений при их простом просмотре огромной массой посетителей форума. Если запрос на просмотр сообщений одновременно подают 200-300 посетителей, и для каждого надо запускать процедуру парсинга - это тяжелый случай. А если парсинг не надо при этом запускать, а просто взять сообщение из БД и отобразить для посетителя - это гораздо легче.
Скорость да наверное возрастет
10. Мелкий - 04 Июля, 2013 - 13:44:19 - перейти к сообщению
sadex пишет:
Что будете делать в аналогичном случае, если форматирование текста сообщений хранится в БД в bb-кодах?
Давайте определимся для начала, про который говорим HTML.
Есть HTML как средство полностью видимое пользователю - фактически, никакой разницы с BB не имеет, только синтаксис чуть другой. Их обоих надо яростно и пристально фильтровать и валидировать.
И есть HTML, который идёт в отрендеринной странице форума. Где совершенно безобидный исходный тег CODE даёт килобайты форматирования. А подсветка синтаксиса имеет свойство совершенствоваться. Например, не было указано слово implements как ключевое. Подсветка должна быть обновлена на всё форуме, что делать?
Вы про хранение в базе которого из?
Я за вариант хранить в базе исходное сообщение (совершенно безразлично что это будет, подмножество HTML или BB), рендер этого сообщения - в мемкэше.
11. sadex - 04 Июля, 2013 - 14:03:32 - перейти к сообщению
Мелкий пишет:
Говорим про html c ограниченными функциями, только для форматирования текста сообщений, т.е некие html-коды аналогичные bb-кодам. Естественно, эти html-теги форматирования видны пользователю при создании и редактировании сообщений, также как видны ему и аналогичные теги bb-кодов. Например,Давайте определимся для начала, про который говорим HTML. ... Есть HTML как средство полностью видимое пользователю...
CODE (htmlphp):
скопировать код в буфер обмена
скопировать код в буфер обмена
- // вместо
- [size=15]текст[/size]
- // ставим
- <span style=font-size:15px>текст</span>
- //вместо
- [color=red]текст[/color]
- //ставим
- <span style=color:red>текст</span>
И т.п. И соответственно, это и храним в БД.
Мелкий пишет:
Уточните, что хранить в БД. Голый текст сообщения с некими метками или же текст сообщения, отформатированный, с тегами bb- или html-кодов. Имхо, есть только два варианта, нормальных, либо хранить в БД текст с bb-кодами, либо текст с html-кодами форматирования.Я за вариант хранить в базе исходное сообщение (совершенно безразлично что это будет, подмножество HTML или BB), рендер этого сообщения - в мемкэше.
Про сам парсер (рендер) здесь речи не идет, речь о том, когда его запускать а когда нет. Если запускать только при создании и редактировании сообщений, то это гораздо меньшая нагрузка на сервер ина систему, чем постоянный запуск парсера при любом просмотре сообщений.
Фильтровать и валидировать bb- или html-коды (теги) форматирования надо только при создании и редактировании сообщений. А это процедура гораздо более редкая чем массовый просмотр сообщений.