Меню
Что нового?

Парсер BBCode на PHP

DpoHro

Новичок
Да я пробовал. Очень хороший класс, я про тот что tashkentchi написал.
Но не нашел я там функции которая бы перегоняла все обратно в HTML.
WP, если хранить только BBCODE и каждый раз делать преобразование, то думаю такой двиг при большом количестве пользователей и большом количестве сообщений на странице будет сильно отжирать ресурсы.
При первом варианте налицо пренебрежение объемом хранимой информации.

Куда экономичнее было бы иметь возможность преобразовать обратно в bbcode лишь при редактировании, ведь редактировать сообщения будут не так часто нежели постить.

Я тут ковырялся в БД IPB и не нашел там признаков хранения информации в 2 экземплярах, да и в bbcode тоже ничего не нашел.
 

Найч

Алгоритмик :-)
boombick
Он не гонит
Попробуй на лету пропарсить 50к текста и выйти на 100запросов/сек. И не забудь это прикрутить к реальной системе, а не абстрактый скрипт на 3 строки
 
boombick

boombick

boombick.org
Попробуй на лету пропарсить 50к текста и выйти на 100запросов/сек
Нажмите для раскрытия...
Никогда не возникало потребности парсить 50-тикилобайтные тексты с бб-кодами... Да и коды имеет смысл использовать только в рамках форумов, гостевух etc... А там тексты по 50 кил не приветствуются
 

DpoHro

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

Ладно, расскажите хотябы кто как делал/делает а я уж сам выберу наиболее подходящий вариант...
 

DpoHro

Новичок
блин со мной бы кто поспорил, я ж вопрос задал :D А то все между собой =)
 
phprus

phprus

Moderator
Команда форума
DpoHro
Лучше хранить 2 версии. Одна с бб-кодом, а вторая преобразованная в html. Толкьо тогда надо будет хранить время создания кеша и время последнего изменения оригинала с BBкодами. А при выводе страницы сравнивать время создания кеша и время последнего изменения. если кеш не устарел то отдавать его иначе перегенерировать html-код. Можно еще хранить время последнего обращения к кешу, чтобы кеши коткорые не использовались больше Х-дней удалялись, для уменьшения БД.
 

ONK

Пассивист PHPСluba
По хорошему, в обсуждаемой библиотеке должен быть инструмент как прямо так и обратного преобразования.
Хранение двух равнозначных версий это неправильно. Можно конечно хранить "мастер версию" и "кэш преобразования", но самое правильное это конечно наличие инструмента двунаправленного преобразования.
 
phprus

phprus

Moderator
Команда форума
ONK
А смысл поддержки двунаправленного преобразования? Я его не вижу.
 

tashkentchi

Новичок
Выложил новую версию: http://www.pc.uz/documents/text/1591.html

Много изменений. Самое большое - создание API, которое позволяет добавлять собственные теги или переопределять умолчальные не изменяя код либы.

-~{}~ 08.03.07 21:52:

Автор оригинала: ONK
По хорошему, в обсуждаемой библиотеке должен быть инструмент как прямо так и обратного преобразования.
Хранение двух равнозначных версий это неправильно. Можно конечно хранить "мастер версию" и "кэш преобразования", но самое правильное это конечно наличие инструмента двунаправленного преобразования.
Нажмите для раскрытия...
1. Пользователь должен получить для редактирования то, что запостил. С точностью до последнего знака. А преобразование HTML - BBCode неоднозначно. Хотябы в силу регистронезависимости в именах тегов BBCode. Поэтому следует хранить именно исходный BBCode.

2. Выигрываем в скорости - проигрываем в дисковом пространстве. Так всегда было, есть и будет. На то и кеширование.

3. Новая версия моей либы позволяет хранить в сериализованном виде результат парсинга ББКода, из которого одинаково однозначно генерится ХТМЛ и восстанавливается ББКод. Но эти сериализованные данные будут весить больше чем ББКод + ХТМЛ.
 
boombick

boombick

boombick.org
tashkentchi
Респект тебе и уважуха
Либу твою активно юзаю - нравится =)
 

dark-demon

d(^-^)b
третий вариант: храним в базе и отдаём xhtml и на клиенте при необходимости формируем bb-code :)
 

tashkentchi

Новичок
Автор оригинала: dark-demon
третий вариант: храним в базе и отдаём xhtml и на клиенте при необходимости формируем bb-code :)
Нажмите для раскрытия...
Хорошая шутка про "на клиенте" :D

Но даже и теоретически не получится. Если Юзер вбил в форму "[TAG]текст[/TAG]", то и получить при редактировании захочет "[TAG]текст[/TAG]" а не "[tag]текст[/tag]". А конвертер xhtml -> bbcode вряд ли сумеет в башке этого юзера поковыряться.

-~{}~ 09.03.07 02:40:

to boombick
Если не тайна, дай ссылки, где мою либу можно в работе посмотреть. Это мне для статистики.
 
nehochuha

nehochuha

Новичок
tashkentchi
Спасибо что выложил скрипт. Ты не мог бы перелицензировать класс на MIT или BSD %)
 

tashkentchi

Новичок
to nehochuha

А с чем связано такое желание?

Если лицензия GPL мешает вам использовать мой скрипт в свободном MIT- или BSD-проекте, то я согласен рассмотреть вопрос о том, чтобы бесплатно предоставить свою либу специально для вашего проекта по лицензии, отличной от GPL.

Если же вы желаете использовать скрипт в проприетарном ПО, то я считаю себя вправе попросить вознаграждение за коммерческую лицензию.

В обоих случаях подробности на мыло.
 

ONK

Пассивист PHPСluba
1. Пользователь должен получить для редактирования то, что запостил. С точностью до последнего знака.
Нажмите для раскрытия...
В рассматриваемом контексте это спорное утверждение. Если клиент прислал мусор из набора тэгов </table></h1></div>..., которые в лучшем случае никак не отображаются а в худшем разрушают структуру документа, то нет смысла хранить этот мусор. Регист генерируемых html тэгов и специальных маркеров не имеет значения для пользователя, а сами "полезные данные пользователя" никак не меняются.
 

tashkentchi

Новичок
Регистр я привел только для примера. Есть и другие неоднозначности.
Например, мой парсер генерит совершенно одинаковый хтмл из следующих конструкций:

1. [nobb] text1 [tag] text2 [/tag] text3 [/nobb]
2. text1 @l;tag@r; text2 @l;/tag@r; text3

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

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