Обработка BBcode

[taster]

В общем, задумался над одним вопросом... Как правильнее сделать обработку BBcode в комментариях?
Допустим, есть функция обработки BBcode. При добавлении сообщении я обрабатываю текст этой функцией и ложу в базу данных. При выводе беру текст из базы и вывожу... Вроде бы все нормально, но...
Что мне делать при редактировании сообщения? Ведь в поле ввода вставляется уже обработанный текст из базы. И вместо BBcode там отображаются html-теги.
У меня пока 2 варианта:
1) Ложить в базу 2 варианта текста: обработанный и исходный. Считаю это неправильным, т.к. объем нужной памяти увеличится в 2 раза.
2) При добавлении сообщения не обрабатывать текст и ложить в базу исходный текст. И при выводе обрабатывать каждый комментарий. Считаю это тоже неверным. Если сообщений на одной странице будет очень много, то генерация страницы будет происходить секунды 2-3 минимум.

Что предлагайте Вы? Какой вариант лучше выбрать? Или есть еще варианты?

 

[Фанат]

генерация страницы будет происходить секунды 2-3 минимум.

ты уже пробовал?

Но в принципе, если действительно очень много, то вместо бб используй HTML и какой-нибудь html putifier, который будет пропускать только разрешенные теги без атрибутов.

 

[taster]

ты уже пробовал?

Да, при выводе 30 комментариев сразу генерация длится 2-3 секунды.

вместо бб используй HTML и какой-нибудь html putifier, который будет пропускать только разрешенные теги без атрибутов.

Основная аудитория моего сайта - обычные пользователи. Они не знают, что такое html и пр.

 

[Фанат]

Они не знают, что такое html и пр.

Это неважно. Что такое ббкод они тоже не знают. Тебя же это не останавливает?

при выводе 30 комментариев сразу генерация длится 2-3 секунды.

ОЙ!
Чем ты их парсишь? троекратным петровским проходом с загибами?

30 должны выводиться 0,03 секунды максимум.
Надо не в консерватории что-то менять, а разбираться, что у тебя там так чудовищно тормозит

 

[taster]

Чем ты их парсишь? троекратным петровским проходом с загибами?
30 должны выводиться 0,03 секунды максимум.
Надо не в консерватории что-то менять, а разбираться, что у тебя там так чудовищно тормозит

Окей, попробую немного оптимизировать. У меня функция работает на методе конечных автоматов. Я думал, так будет быстрее. Сейчас сделаю обработку обычными регулярками.

 

[taster]

Теперь при обработке обычными регулярками страница генерируется 0.1 - 0.4 сек. Меня это вполне устраивает. Осталось немного профиксить.
Тему можно закрывать.
Фанат, спасибо.

 

[hell0w0rd]

А почему не хранить одновременно два варианта? При постинге обрабатывать и записывать. На редактирование отдавать сырой bb, на обычный запрос - чистый html?

 

[taster]

А почему не хранить одновременно два варианта? При постинге обрабатывать и записывать. На редактирование отдавать сырой bb, на обычный запрос - чистый html?

База ведь не резиновая. Если у меня over100500 комментариев, то в базе будет хранится в 2 раза больше.

 

[Фанат]

100500, пусть даже по 500 байт.
100500 * 500 / (1024 * 1024) = 50 метров. х 2 будет сто.
Что-то мне не кажется цифра в сто мегабайт гигантской.

А 0.4 - это тоже много. при превышении 0.1 я бы начинал беспокоиться.

 

[hell0w0rd]

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

 

[taster]

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

А можете поделиться ссылками на статьи про это кеширование?

 

[WMix]

http://www.google.com/search?q=статьи+про+кеширование+php

 

[hell0w0rd]

а какие статьи тут нужны? в данном случае кеширование заключается в разовом парсинге bb кодов и записи результата.
менюшку можно кешировать строкой в файл, или в мемкеш и тому подобные
могу поделиться ссылкой на компонент для кеширования различными способами: https://github.com/doctrine/cache

 

[fixxxer]

Я все равно в упор не понимаю, почему "обычному пользователю" [ b ] - легко, а <b> - непостижимый рокетсайенс.

Для обычных пользователей делают WYSIWIG.

 

[AnrDaemon]

1. Если вы задавались вопросом "а как это делают другие", то, например, в phpBB (2.x) BB-коды обрабатывались в два приёма.
Перед записью в БД код комментария парсился и все валидные (парные, в правильном порядке, и т.п.) ББ-коды снабжались хешем. Долго и нудно, зато надёжно. Но только один раз.
При выводе сообщения только коды, снабженные хешем, заменялись на HTML. Тупо. Просто. И очень быстро.
2. Что вы к этим ББ-кодам привязались? Чем вики форматирование на двойных символах не угодило? По-моему, намного нагляднее.

 

[lLoKeRl]

В базе BB храни, а при выводе обрабатывай функцией, что сложного ?

 

[hell0w0rd]

В базе BB храни, а при выводе обрабатывай функцией, что сложного ?

А чего сложного хранить два варианта?

 

[lLoKeRl]

А чего сложного хранить два варианта?

Да зачем там два варианта вообще ? Что за велосипеды ?

 

[hell0w0rd]

Да зачем там два варианта вообще ? Что за велосипеды ?

Ну парсинг чего бы то нибыло дорогая операция, и записывать вы явно реже будете, чем читать, за этим и надо

 

[lLoKeRl]

Ребятки, когда у Вас будет посещаемость 10к + может тогда и стоит подумать об оптимизации, а так не вижу смысла!