LINUX.ORG.RU

[бебекод] А почему в бордах хранят сообщения не прямо в html?


0

2

Насколько я знаю по vBulletin и ipb, борды хранят сообщения в базе в виде ббкода. Решение спорное, та как для быстрой отдачи требует кеша. Мне видится более правильным такой вариант - простые теги парсить в html напрямую, а сложные парсить в div, но при этом сохранять метаданные в data-*, чтобы не потерять исходный синтаксис.

Из профитов - очень шустрая отдача. Лишнее из data можно почикать простыми регулярками. Еще можно часть парсинга на клиенте «доводить». Например, менять ссылки на ютюб на подходящий видеоплеер, определяя возможности клиента по месту.

Дискас. Какие могут быть проблемы? Список валидных тегов и их параметров лимитировать вроде не сложно. Если знаете - приведите примеры форумов или чего-то похожего, которые имеют богатую разметку, но при этом хранят данные сразу в html.

★★★★★

Потому что в вебе всем глубоко похрен на производительность. Было бы не похрен - при посте юзера тупо генерировали бы страницу треда целиком и далее отдавали бы статикой.

legolegs ★★★★★ ()

сделай замер апач-бенчмаркером бб->хтмл, бб->недохтмл->хтмл и недохтмл->хтмл, почти уверен что разницы даже 5% едва наберется

anonymous ()
Ответ на: комментарий от anonymous

Разница проверяется гораздо проще - отключением кеша на вобле. Дык вот без кеша сильно грустнее.

Да, и я предлагаю делать не недохтмл, а полностью валидный хтмл с дополнительными метаданными в data. Его можно показывать «как есть», и будет выглядеть правильно. Стандартный подход - хранить в базе превдоразметку редактора, а по ней генерить «как-нибудь потом» странички. Я предлагаю хранить «странички», а разметку генерить обратно только при редактировании.

Vit ★★★★★ ()
Ответ на: комментарий от Eddy_Em

На хоботе так и делают, емнип. да и хранить сотню тысяч файлов - вообще не вопрос.

legolegs ★★★★★ ()

Что интересно, на всяких там анонимных имиджбордах вроде wakaba именно так и делают.

AITap ★★★★★ ()
Ответ на: комментарий от AITap

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

Vit ★★★★★ ()

Я предлагаю писать сообщения на html, а при отправке парсер будет проверять их и не даст запостить, если будут какие-то левые теги.

gentoo_root ★★★★★ ()
Ответ на: комментарий от gentoo_root

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

Vit ★★★★★ ()

Хранение сгенерированного ХТМЛ в БД рядом с оригинальными данными, это и есть один из видов кеширования, к которому вы так презрительно относитесь.

provaton ★★★★★ ()
Ответ на: комментарий от provaton

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

Vit ★★★★★ ()

Тогда уж лучше использовать Filtered HTML. Какая принципиальная разница между ним и BB Code? Разве что чисто визуально при редактировании. Ну так аналог BUEditor нас спасёт.

Chaser_Andrey ★★★★★ ()
Ответ на: комментарий от Chaser_Andrey

Напишите пожалуйста простой пример. Как хранить цитату в базе. У цитаты 4 параметра - автор, ID оригинала, время, цитируемый текст. На выходе оно генерит несколько DIV-ов. Естественно, надо уметь восстановить все параметры, если юзер захочет отредактировать текст в визивиге.

Vit ★★★★★ ()
Ответ на: комментарий от JFreeM

Цитаты, выравнивание текста, автопреобразование ссылок на видео в плееры. Возможно, еще темплейты типа виковских, для статей.

Vit ★★★★★ ()

мы хранили метадату, а html кэшировали/удаляли из кэша при пересечении метрик (первое обращение, заполнен диск с кэшем, итп). Заодним так можно иметь несколько кэшей.

stevejobs ★★★★☆ ()
Ответ на: комментарий от stevejobs

В вобле именно так и делается. Аж по кешу на скин. Есть 2 проблемы:

1. Сильно раздувает базу (или сжирает память, которую можно было отдать под базу).

2. Если какие-то теги хочется парсить на стороне клиента, требуется дополнительная химия, как в HTML обозначить эти теги и метадату. То есть, надо делать еще один велосипед.

Суть моего гениального предложения в том, чтобы одним махом аннигилировать сразу всех зайцев. До этого была гениальная мысль хранить в базе DOM, но вроде бы HTML с метой в data-* будет компактнее, «понятнее», и менее велосипедно.

Пока хочу понять консистентность подхода. Нашел только, что не получится сделать динамические теги «этот текст скрыт от пользователей, у которых меньше 10 постов». Но без таких извратов я переживу. А пример с видео прекрасно отпарсится на клиенте.

Vit ★★★★★ ()
Ответ на: комментарий от JFreeM

Ну мы же взрослые люди, давайте достанем и померяем. Примеры в студию.

Vit ★★★★★ ()

> Из профитов - очень шустрая отдача.

Не делайте мне смешно. Шустрая отдача это отдача из мемкеша, а кешировать хтмл в мускуле, это такой же цирк как и mod_php в целом.

В вебе, без кеширования, никакой производительности нет и быть не может.

redixin ★★★★ ()
Ответ на: комментарий от Vit

решил получить скорость, рискнув расширяемостью? )) Ну, идея, чо.

кстати, может возникнуть проблема: искаробочный mysql плохо держит нагрузки и нифига не масштабируется. Дурацкая ситуация: всего тысяча пользователей, и 100500 серверов стоят без дела из-за горлышка в мускуле. А ты именно на него собираешься положиться =)

stevejobs ★★★★☆ ()
Ответ на: комментарий от stevejobs

> решил получить скорость, рискнув расширяемостью? )) Ну, идея, чо.

Тут дело такое - за 10 годков я успел наизусть выучить все нужные и все ненужные ббкоды. Проверить просто - расписать, как транслируется каждый. Абстрактная масштабируемость и расширяемость - путь в никуда^W ынтырпырпрайс. Эмбеддить бебекодом экселевские таблички мне ни нада.

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


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

Vit ★★★★★ ()
Ответ на: комментарий от Vit

> и обсудим формат хранения.

ты же в оп-посте уже всё обсудил, или есть еще что-то? ;-)

stevejobs ★★★★☆ ()

>Насколько я знаю по vBulletin и ipb, борды хранят сообщения в базе в виде ббкода.

Не знаю вообще vBulletin и IPB, но неужели каждый раз этот BB-код конвертируется в HTML? Глупо как-то. Грамотно — это хранить и исходный пост, и отформатированный. При просмотре отдавать отформатированный, а при редектировании поста юзером показывать исходный. Так сделано в LiveStreet, например.

Wizard_ ★★★★★ ()
Ответ на: комментарий от legolegs

>при посте юзера тупо генерировали бы страницу треда целиком и далее отдавали бы статикой

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

Wizard_ ★★★★★ ()
Ответ на: комментарий от legolegs

>Потому что в вебе всем глубоко похрен на производительность. Было бы не похрен - при посте юзера тупо генерировали бы страницу треда целиком и далее отдавали бы статикой.

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

anonymous ()
Ответ на: комментарий от Vit

>Да, и я предлагаю делать не недохтмл, а полностью валидный хтмл с дополнительными метаданными в data. Его можно показывать «как есть», и будет выглядеть правильно. Стандартный подход - хранить в базе превдоразметку редактора, а по ней генерить «как-нибудь потом» странички. Я предлагаю хранить «странички», а разметку генерить обратно только при редактировании.

А ты уверен, что всё нужное для редактора влезет в data-*? А то выйдет так, что эта дата будет по размеру как сообщение.

Но это ерунда. Лучше приведи пример того, как оно будет выглядеть, т.к. есть сомнения, что аттрибутов data-* хватит на все случаи жизни. Ведь если ты у них будешь, допустим, засовывать bbcode, то твои html-тэги по структуре и вложенности должны будут соответствовать структуре этого кода.

У тебя есть:

[tag1] something [tag2] something2 [/tag2] .... [/tag1]

Значит твой html будет, допустим,

<div class=«someclass» data-bbcode=«tag1»> something <span data-bbcode=«tag2»> something2 </span> .... </div>

А если разметка html совсем не совпадает с ббкодом? То есть надо сделать 3 дива и что-то там внутри? Как ты будешь раскидывать ббкод по дате, когда структура не совпадает.

anonymous ()
Ответ на: комментарий от anonymous

Про веб почему-то часто продолжают думать, что это удел недалёких пых-пых кодеров. Что туда может придти какой-нибудь сишник и с налёту всё сразу порешать, ни разу не написав ни одного сайта. А это же уже очень давно не так. Веб — это отдельная ниша, в которую тоже очень долго надо въезжать, если этим не занимался серъёзно до этого.

Wizard_ ★★★★★ ()

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

moscwich ()
Ответ на: комментарий от anonymous

> А ты уверен, что всё нужное для редактора влезет в data-*? А то выйдет так, что эта дата будет по размеру как сообщение.

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

А если разметка html совсем не совпадает с ббкодом? То есть надо сделать 3 дива и что-то там внутри?


у ббкодов 2 типа параметров - опции и содержимое (в тех, что я знаю). Опции всегда идут в data. Содержимое - либо внутрь тега, если есть неделимая часть, либо, в худшем случае - в data для бакапа.

Если генерится несколько html-тегов, то классами помечаем, какие из них автоматические, а какой содержит параметр ббкода. Для одного из самых сложных случаев, цитат, вроде прокатывает.

[quote=«nick;src_id;timestamp»]цитируемый текст[/quote]

<div class=«quote» data-options=«nick;src_id;timestamp»>
<div class=«generated quotehad»>заголовок с именем автора и ссылкой на оригинал</div>
<div class=«quote_text»>цитируемый текст</div>
</div>

Как ты будешь раскидывать ббкод по дате, когда структура не совпадает.


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

В теоретическом сложном случае, когда надо в data сохранить сложную вложенную структуру, а не строку - можно сериализовать. Не шибко красиво, конечно, но я таких случаев пока просто не смог придумать. Из тех тегов, которые знаю. Если сможете придумать пример - попробую расписать.

Vit ★★★★★ ()
Ответ на: комментарий от lazyklimm

> а bb вообще говно и не нужен. Я не понимаю, чего он так получил распространение.

Поддерживаю.

moscwich ()
Ответ на: комментарий от Vit

>В худшем случае будет размером с исходную часть ббкода. Но ведь хранить и так и эдак пришлось бы.

Мне кажется, что ты слишком сильно волнуешься на тему размера БД. Как бы банально это не звучало, но место сейчас дешевое, и гораздо лучше упростить код, чем экономить даже половину размера базы.

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

Тем более экономя место ты делаешь проблему в другом - увеличиваешь размер выводимого html, добавляя трафик. Я бы не стал так легко решать, что важнее - трафик или размер БД. Пользователь выберет первое, кстати. Ему хлам в data-* (которая не для этого придумывалась) не нужен.

Единственный пример, который знаю - замена ссылок на встроенное видео.

Это сейчас. А представь, что до проекта доберётся шибко умный дизайнер-верстальщик, и придётся расставлять какие-нибудь хитрые div-ы и span-ы, для сложного вывода цитат. Потом будет очень обидно.

Делать одинаковый по стилю шаблон, как сделано на всех *bb форумах - несерьёзно в 2011 году. Надо делать так, чтобы шаблон можно было менять не кусками, а полностью, вплоть до замены конвертера bbcode=>html и полной смены расположения элементов.

Иначе получится уныние как phpbb, где темы отличаются только парой картинок и расцветкой. И интеграция в готовый сторонний сайт будет представлять собой ад.

В теоретическом сложном случае, когда надо в data сохранить сложную вложенную структуру, а не строку - можно сериализовать.

Ты изобретаешь монстра на пустом месте:)

anonymous ()
Ответ на: комментарий от Vit

>В html нет подходящих аналогов.

а кто говорит про html? Есть вполне себе адекватный и легче парсящийся (в том числе человеком, так как читабельность страдает минимально) Markdown, например

lazyklimm ★★★★★ ()
Ответ на: комментарий от anonymous

> Мне кажется, что ты слишком сильно волнуешься на тему размера БД. Как бы банально это не звучало, но место сейчас дешевое, и гораздо лучше упростить код, чем экономить даже половину размера базы.

Код-то не упрощается. Парсить надо что там что там. На ббкоде ж тоже надо дерево строить и копаться в нем. Кастомное говно сочинять. А у меня html везде - парсеры стандартные. От ббкода одно название осталось, чтобы подчеркнуть наличие quote и прочих хитротегов.

Так что у меня проще получается, как ни крути. Я вообще не планирую давать людям ковырять сорец. Пусть через визивиг работают. Ббкодной разметки даже в промежутках не будет - только валидный HTML. Просто у визивига будут плагины для удобного отображения.

Тем более экономя место ты делаешь проблему в другом - увеличиваешь размер выводимого html, добавляя трафик.


Да не добавляется он. Служебные data перед отдачей вырежутся регуляркой. Если и можно прикопаться - до скорости регулярки только. Но я ими гигабайтные данные обрабатывал под сфинкс - быстро там все, проверено.

А представь, что до проекта доберётся шибко умный дизайнер-верстальщик, и придётся расставлять какие-нибудь хитрые div-ы и span-ы, для сложного вывода цитат. Потом будет очень обидно.


Делать одинаковый по стилю шаблон, как сделано на всех *bb форумах - несерьёзно в 2011 году. Надо делать так, чтобы шаблон можно было менять не кусками, а полностью, вплоть до замены конвертера bbcode=>html и полной смены расположения элементов.


Не согласный я. Во-первых, за 10 лет таких случаев ни разу не было. Во-вторых, сейчас идет упор на семантику и оформление через CSS.

И потом, никто не мешает хранить у записи ID формата, на всякий случай. Это все равно полезно, если хочется местами использовать маркдаун, которые парсится на лету С-шными библиотеками, как на гитхабе. При смене формата можно либо динамически парсер выбирать при редактировании, либо базу конвертнуть в свободное от загрузки время.

Vit ★★★★★ ()
Ответ на: комментарий от lazyklimm

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

Vit ★★★★★ ()
Ответ на: комментарий от Vit

>богатства разметки маркдауна мне мало

markdown extra, textile etc

Опять же, осмелюсь предположить, что для 99% постов в интернете маркдауна с расширениями более чем достаточно.

lazyklimm ★★★★★ ()
Ответ на: комментарий от lazyklimm

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

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

Vit ★★★★★ ()
Ответ на: комментарий от Vit

>Давайте не будем считать себя гениальнее других.

не считаю

распишите в ней сначала цитату с несколькими параметрами

например?

lazyklimm ★★★★★ ()
Ответ на: комментарий от lazyklimm

http://www.linux.org.ru/jump-message.jsp?msgid=6534733&cid=6536453
http://nodeca.github.com/nodeca-design/forum-posts.html

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

Vit ★★★★★ ()
Ответ на: комментарий от Vit

>Код-то не упрощается. Парсить надо что там что там. На ббкоде ж тоже надо дерево строить и копаться в нем. Кастомное говно сочинять. А у меня html везде - парсеры стандартные. От ббкода одно название осталось, чтобы подчеркнуть наличие quote и прочих хитротегов.

Однако всё же парсить один раз сообщение при сохранении проще, чем гонять его туда-обратно при каждом редактировании. Ведь всё равно придётся возиться с data-*.

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

А не проще тогда воткнуть какой-нибудь ckeditor для html, а при сохранении просто резать неправильные тэги?

Да не добавляется он. Служебные data перед отдачей вырежутся регуляркой. Если и можно прикопаться - до скорости регулярки только. Но я ими гигабайтные данные обрабатывал под сфинкс - быстро там все, проверено.

Тогда да, проблемы нет.

Не согласный я. Во-первых, за 10 лет таких случаев ни разу не было. Во-вторых, сейчас идет упор на семантику и оформление через CSS.

Учитывая то, что браузеры всё ещё разные, и рендеринг в них отличается, через CSS отнюдь не всё можно сделать. А если и можно, то могут появиться просто дикие костыли и хаки.

А то, что таких случаев не было - ничего не значит. Вот появится ынтерпрайз-клиент, которые захочет эту штуку сделать именно так, а её переписывать придётся. Обидно делать систему, в которой что-то прибито гвоздями, если при этом изначально можно этих гвоздей избежать.

anonymous ()
Ответ на: комментарий от anonymous

> Однако всё же парсить один раз сообщение при сохранении проще, чем гонять его туда-обратно при каждом редактировании. Ведь всё равно придётся возиться с data-*.

Бебекод-то в визивиг тоже надо гонять. И это намного гиморнее, потому что свой парсер бебекода сочинять. Визивиг html хочет. А у меня можно готовые библиотеки взять и культурно c DOM поработать, подогнав под требования визивига.

А не проще тогда воткнуть какой-нибудь ckeditor для html, а при сохранении просто резать неправильные тэги?


А так и будет. Просто в данном посте хотелось бы обсудить именно формат хранения-отдачи. С упором на простоту и скорость.

А то, что таких случаев не было - ничего не значит. Вот появится ынтерпрайз-клиент, которые захочет эту штуку сделать именно так, а её переписывать придётся. Обидно делать систему, в которой что-то прибито гвоздями, если при этом изначально можно этих гвоздей избежать.


Писал уже про ынтырпрайз http://www.linux.org.ru/forum/web-development/6534733?lastmod=1311687941769#c... .

А тут в конце про смену формата http://www.linux.org.ru/jump-message.jsp?msgid=6534733&cid=6539497

Vit ★★★★★ ()

>Насколько я знаю по vBulletin и ipb, борды хранят сообщения в базе в виде ббкода.

iPB хранит в виде HTML и при редактировании делает обратное преобразование HTML → BBCode. Идиотизм ужасный.

На вменяемых движках хранится исходный текст юзера + HTML-кеш для вывода.

Из профитов - очень шустрая отдача. Лишнее из data можно почикать простыми регулярками


Шустрая отдача — это когда вообще ничего чикать не надо.

KRoN73 ★★★★★ ()
Ответ на: комментарий от lazyklimm

>что для 99% постов в интернете маркдауна с расширениями более чем достаточно

Оставшийся 1% часто бывает очень важен. Ибо, как раз, при простом трёпе на разметку пофиг, а проблемы лезут, когда нужно сделать что-то полезное.

KRoN73 ★★★★★ ()
Ответ на: комментарий от Vit

>Пусть через визивиг работают. Ббкодной разметки даже в промежутках не будет - только валидный HTML.

Разные браузеры через WYSIWYG выдают совершенно разный код. Нередко — несовместимый. Уж я с TinyMCE на этих граблях пляшу, пляшу…

Всё же, ИМХО, BBCode (опиционально — с элементами Markdown) на сегодня (как и в последние 15 лет) самый оптимальный вариант. А юзеру можно дать ещё выбор, чистый BBCode или BBCode/WYSIWYG (менее гибко, но наглядно).

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

> iPB хранит в виде HTML и при редактировании делает обратное преобразование HTML → BBCode. Идиотизм ужасный.

Речь о новых версиях, а не первой ветке с говном в комментариях.

На вменяемых движках хранится исходный текст юзера + HTML-кеш для вывода.


Ну да, мозгов-то лучше сделать не хватило. И не стоит путать «нормальные» и «распространенные».

Vit ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.