cotonti.com : Зачем в базе 2 раза сохраняется текст?

Trustmaster

пт, 31 июл 2009 02:58:41 -0000

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

Sergey

пт, 31 июл 2009 02:51:41 -0000

Вот как раз об этом я старался донести мысль в http://www.cotonti.com/forums.php?m=posts&id=15066
Что надо "меньшинству дать возможность прикрутить что-то своё для решения любой проблемы." т.е прикрутить соответствующее поле для выборки (ввода) решений хотя бы для имеющегося парсера. А так, нет ничего забавнее, чем смотреть, как на телефоне воспроизводятся их собственные тесты и примеры.

Trustmaster

пт, 31 июл 2009 02:28:39 -0000

Что-то я перестаю понимать, о чём речь. Кажется, уже о том, что для разных мобильных устройств надо один и тот же ббкод отображать по-разному. Ну это уже дополнительный парсер писать, однозначно. Как - это уже ваше дело. Мы "из коробки" стараемся поставить то, что устроит большинство, а меньшинству дать возможность прикрутить что-то своё для решения любой проблемы.

Sergey

пт, 31 июл 2009 00:57:03 -0000

Чем замечателен этот редактор (как впрочем и в седе), замечателен тем, что если нажал "Предпросмотр", так всё послание и исчезло, и восстановлению не подлежит ( а заодно и остыл)
Вот я тут сработал на своем парсере два примечательных примера: parser_205.zip для одного меню:

[class=кнопка;пункт]
1 кнопка для проверки
2 купите бананы
3 статья про картошку
4 пошлите арбуз
[/class=]

Оба варианта для одного и того же телефона марки нокиа. только один для случая браузера S40 (или как там у них) а другой для миноперы. Так, что стандарты html-кеш тут неприемлемы. Если, кто-то считает, что в два прихлопа (скин и css) в в один присид (плуг) проблема решается, то смею разочаровать, не получится - потребовался дополнительный парсер. Самое веселое у них на одном и том же телефоне понятие выделенный шрифт совершенно по разному т.е. ббкод соответствующий не прокатит и так в каждом случае "html-кеш - это только для стандартного". Хочется-не хочется, но придется ускорять парсер. Надеяться, что каждый приобретет убийцу компьютеров (это их реклама) Nokia N97 не приходится, но будем ждать подвижек.

Trustmaster

чт, 30 июл 2009 21:25:39 -0000

Нет, html-кеш - это только для стандартного. Так что если есть желание процентов на 15 повысить нагрузку на сервер, то действуйте.

jcrush

чт, 30 июл 2009 20:21:52 -0000

Получается если отключить парсер, то поле не будет заполняться? следовательно можно написать свой pars.php или он так же будет сохраняться в базу?

Boss

чт, 30 июл 2009 17:36:46 -0000

# Sergey : ... А какова скорость работы таких реализаторов, как правило совпадает со скоростью чтения файла, т.е чтения кэша. А возможности? Они беспредельны для дизайнеров типовых решений ...

Правильно уже сказали выше. Если нужно, то никто не запрещает это делать для себя. Но встраивать в движок не нужно. По скорости такое решение может лишь приближаться, и, в лучшем случае, соответствовать кэшу. А функциональность лично меня и сейчас устраивает. Для меня главное легкость и прозрачность решения. Сложности мне ни к чему.

ps: Была бы моя воля, я бы и сейчас из котонти выкинул функцию занесения бб-кодов через админку в базу. У меня там сейчас лишь десяток кодов используется, от которых впрочем тоже можно отказаться, остальное в собственном парсере уже давно.

Trustmaster

чт, 30 июл 2009 15:29:47 -0000

Был тут у нас один конечный автомат с рекурсией и семантикой - xBB называется. И по скорости он вчистую проиграл стандартному парсеру Котонти, не говоря уже о "чтении статичного кеша". Можете поискать на форуме, там нехилые дебаты были.

Ни один парсер на PHP, будь он трижды быстр и четырежды удобен, не сможет дать такого снижения нагрузки, как HTML-кеш. Тем не менее, мы никого не заставляем использовать встроенный парсер. Хочется рекурсивной магии и взаимообратных преобразований - реализуйте, подключайте.

Sergeich

чт, 30 июл 2009 15:23:49 -0000

Sergey, ну если всё так замечательно, то может попробуете это реализовать в тестовом варианте, тогда можно будет сравнить производительность и удобство и того и другого вариантов :).

Sergey

чт, 30 июл 2009 14:53:15 -0000

# jcrush : не вижу очевидных плюсов такого парсера, в одном плюс в другом большой минус, а пользовательские ббкоды немногие юзают.

Без обид. А вы когда-нибудь писали для YACC и LEX? А вы знаете как устроены трансляторы, анализаторы и пр.?

jcrush

чт, 30 июл 2009 14:48:02 -0000

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

Sergey

чт, 30 июл 2009 14:37:24 -0000

Для того,чтобы понять как работают такие парсеры, достаточно познакомится с YACC и LEX в юниксе. Как это работает. Пишется грамматическое дерево разбора и отдельно пишется лексический анализатор все очень похоже на существующую базу ббкодов. В чем фишка парсера (YACC) он транслирует не текст страниц, он транслирует в дерево разбора сам разбор ббкодов. В результате получается компактная таблица переходов анализатора разбора - получается автомат. Затем, имеется очень короткая программа, которая просто читает текст в один проход!! и обнаружив ликсему типа [имя] или [/имя] генерирует код лексемы, программа, будем называть ее реализатор (она как правило крайне мала по размерам) в соответствии с таблицей разбора, назначает действие из другой таблицы (каждое правило грамматического разбора подразумевает действие). В чем прелесть такой системы. Прежде всего рекурсивность разбора, что дает делать совершенно немыслимые действия. А что вставляется в серверную часть? как раз не парсер, а вот этот реализатор с таблицей. Сам парсер запускают один раз, в случае изменения либо набора лексем, либо правил грамматического разбора. А какова скорость работы таких реализаторов, как правило совпадает со скоростью чтения файла, т.е чтения кэша. А возможности? Они беспредельны для дизайнеров типовых решений: например: вот как будет с рекурсивным разбором (придумано по ходу)
[b[red]] текст та-та - та и что- то написано красным что-то на выходе отмеченное красным будет еще и жирным. И так далее. Тут главное придумать смелые правила - рекурсия решает многое.

Sergeich

чт, 30 июл 2009 14:11:03 -0000

Sergey, одна из фич котонти - возможность добавлять свои теги довольно простым путём, причём теги можно мутить довольно сложные и специфичные. Если внедрять парсер туда-сюда-обратно, то придётся, если я правильно понимаю, для каждого тега прописывать ещё и правила обратных преобразований не забывая о безопасности, плюс каждое преобразование - дополнительная нагрузка на сервер. Это, на мой взгляд, уже перебор. Я из двух зол выбираю меньшее - увеличение базы за счёт раздельного хранения html и bb, тем более дисковое пространство сейчас наименее затратная часть хостинга.

Boss

чт, 30 июл 2009 13:52:26 -0000

По-моему сейчас реализация самая правильная. Постоянно преобразовывать тест из BB в HTML и обратно глупо. Благо разработчики это понимают. Если бы было постоянно преобразование, то на котонти можно было бы смело ставить крест.

Конечно, база стала в два раза больше, но полезность кэша очевидна.

ps: Статистика моей базы на котонти:

БД SQL, число строк 244601
БД SQL, размер индекса (KB) 145 502.0
БД SQL, размер данных (KB) 111 872.1
БД SQL, общий размер (KB) 257 374.1

У кого-нибудь есть больше?

Sergey

чт, 30 июл 2009 13:34:34 -0000

Надо поставить парсер http://greg.chiaraquartet.net/archives/137-a-parser-generator-for-PHP-finally.html настроить таблицу тегов и получим скоростной парсер с исправлением ошибок - дело за малым: решиться.

Sergeich

чт, 30 июл 2009 13:20:55 -0000

А как разбор пользовательских тегов делать?

jcrush

чт, 30 июл 2009 07:43:35 -0000

Что там неравнозначного? основные ббкоды можно в хтмл парсить и обратно, в DLE это прекрасно реализовано!

Trustmaster

ср, 29 июл 2009 22:13:51 -0000

А как ты собираешься редактировать ббкоды, если всё уже в HTML? Это ведь отнюдь не взаимно-однозначное преобразовние.

jcrush

ср, 29 июл 2009 21:18:48 -0000

все равно какой смысл два раза в базе одно и тоже? хранить все в хтмл а парсить при редактировании добавлении.

Trustmaster

ср, 29 июл 2009 15:41:25 -0000

А чем оно мешает?

jcrush

ср, 29 июл 2009 13:45:15 -0000

т.е. кеш не на всю базу? а только на часто открываемые страницы? как бы так по хорошему должно быть...

Boss

ср, 29 июл 2009 12:58:03 -0000

Там в админке вроде отключается если тебе не надо HTML-кеш. Запись будет производится только в text.

Sergeich

ср, 29 июл 2009 12:56:06 -0000

В поле html хранится отпарсеный ББ-код, собственно, это тот самый html-кеш :). При формировании страницы движок берёт готовый кусок кода, а не парсит каждый раз ББ.

jcrush

ср, 29 июл 2009 07:56:53 -0000

Заметил что в таблице постов форума, как подозреваю и страницах мы храним два раза один и тот же текст - тело сообщения 1. в text и html, как я понимаю это надо для ббкоде, но все же за счет этого вся база в 2 раза растет неоправданно, разве других решений нет?

`sed_forum_posts` - `fp_html