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

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

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

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

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

>отключением кеша на вобле.

Там же ещё и запросы к БД кешируются. А они как раз самая тормозная часть.

Эдак пришлось бы помимо основной БД хранить еще 100500 нагенерированных страничек...

Идите в толксы уже юморить.

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

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

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

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

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

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

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

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

>Там разметка ограничена маркдауном, а мне требуются более сложные вещи.
какие например?

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

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

>Цитаты, выравнивание текста, автопреобразование ссылок на видео в плееры.
вы не поверите...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>Да, и я предлагаю делать не недохтмл, а полностью валидный хтмл с дополнительными метаданными в 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 дива и что-то там внутри? Как ты будешь раскидывать ббкод по дате, когда структура не совпадает.

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

Это я про этого legolegs, если чё.

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

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

> А ты уверен, что всё нужное для редактора влезет в 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 сохранить сложную вложенную структуру, а не строку - можно сериализовать. Не шибко красиво, конечно, но я таких случаев пока просто не смог придумать. Из тех тегов, которые знаю. Если сможете придумать пример - попробую расписать.

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

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

Для простой разметки - не нужен. Нужен для сложной, типа цитат. В html нет подходящих аналогов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

markdown extra, textile etc

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

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

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

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

не считаю

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

например?

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

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

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

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

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

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

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

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

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

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

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

> Однако всё же парсить один раз сообщение при сохранении проще, чем гонять его туда-обратно при каждом редактировании. Ведь всё равно придётся возиться с 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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