DeepVarvar, благодарю за интерес к теме. Решение рабочее, но какое-то оно ... не очень красивое.
Пока надумал вот что.
1. Админ. Сообщения (статьи, новости и т.д.), создаваемые админом (в админке), создаются html-резметке. Простая валидация (контроль ошибок) на клиенте, с реализацией предпросмотра в html. Фильтрация html на сервере (защита от XSS и др. атак). Далее, запись и хранение в БД в html. Редактирование в html (простой редактор html-разметки). Вывод и показ сообщения - в html без парсинга. Узкое место - фильтрация html на сервере, но поскольку это сообщение от админа из админки, то фильтр можно делать простой, не слишком мощный.
2. Пользователь. Сообщения (комментарии и т.д.), создаваемые пользователем, создаются в bb-кодах разметки текста. Простая валидация (контроль ошибок) на клиенте, с реализацией предпросмотра в html (для этого есть простой парсер на JS из bb в html). Далее, на сервере, парсинг из bb в html, запись и хранение в БД в html. Редактирование пользователем - обратный парсинг из html в bb (на сервере или на клиенте - еще не понял, где лучше), редактирование в bb, дальше повторение дейстивий при создании сообщения. Вывод и показ сообщения - в html без парсинга. Узкое и неоптимальное место - редактирование. Но поскольку для юзеов (только для превилигированных) это будет довольно редкой процедурой (по сравнению с просмотром) - то это допустимо.
При описанном выше решении достигается главная цель - при просмотре сообщений (по запросу от любого посетителя сайта) они достаются из БД и выводятся в браузер без парсинга bb в html, т.е. быстро и с минимальной нагрузкой на сервер. А поскольку просмотр - это наиболее частая процедура, то такое решение, имхо, довольно оптимальное и привлекательное.
Критика, продуктивная, приветствуется. Заранее благодарен всем участвующим в обсуждении за интерес к теме.
В своей микро-CMS делаю пока два варианта, для экспериментов.
1. Сообщение от юзеров (комментарии и т.п.) - создаются с разметкой в bb-кодах, парсятся на сервере в html перед сохранением в БД, в html достаются из БД и выводятся. Узкое место - редактирование юзерами таких сообщений. Для этого нужно делать обратный парсинг из html в bb-разметку, но это приемлемо, с учетом относительно редких случаев редактирования. Еще кое-что. Для реализации предпросмотра на клиенте в JS делается простой парсет из bb в html разметку текста.
2. Сообщения от админа (статьи, новости и пр.), которые создаются в админке, создаются с текстовой разметкой в html. В ней же отсылаются на сервер и сохраняются в БД. В ней же, без парсинга, отображаются на сайте. Узкое место - фильтрация html от XSS и прочих атак. Но это приемлемо, с учетом того, что админка доступа админу но не хакерам, и админ свой сайт атаковать не будет.
Цель. Удаление из текста сообщения (комментария и пр.) юзера контейнеров типа <script...>code...code</script>. Исходные условия. Сообщение от юзера, в общем случае, может приходить как в bb- так и в html текстовой разметке. Регулярка работает в php-скрипте на сервере (способ в JS-скрипте на клиенте не рассматривается).
Тестирую свой форум в рунете. Заметил, что при небольшой БД MySQL происходит чрезмерное потребление памяти на сервере хостера при генерации страниц форума. Например, такая строка статистики:
[ Сгенерировано за 0.007 сек, 7 запросов выполнено - Использовано памяти: 41.19 MB (Пик: 43.06 MB) 04.07.13 19:27:40 ]
На локальном сервере, когда заливаю дамп той же самой БД на локальный форум, имею такую строку статистики:
[ Сгенерировано за 0.028 сек, 9 запросов выполнено - Использовано памяти: 1.38 MB (Пик: 1.47 MB) 05.07.2013 05:52:00 ]
На других серверах в рунете тот же форумный движок FluxBB 1.5.3 с гораздо большим объемом БД чем у меня использует памяти при генерации страницы примерно 1.5-2 Мб. А у меня - 41-43 Мб. Это слишком много.
Я новичек в PHP и MySQL, прошу корифеев подсказать, куда копать, как решить проблему. Чрезмерно грузить сервер хостера мне совсем не хочется.
Почему любом? Только того, которого нет в мемкэше.
Это не выход, просмотров, к которым обращаются впервые, при хорошей посещаемости всегда много.
Мелкий пишет:
А что вы хотите хранить для банального описанного мной случая с тегом CODE?
Пока не знаю. Но есть варианты. Один - не каждый форум (блог, сайт) в инете для программистов, и тег code при этом не будет нужен. Другой - в HTML есть свой тег code, его и можно хранить. Форматирование кодов при этом гораздо беднее, чем здесь на форуме, но часто - сойдет. Третий - попробовать сделать функционал для кода не хуже, чем здесь, но это совсем не банальный вариант.
Мелкий пишет:
...писать не только рендер этого подмножества форматирования (урезанный HTML или BB), но и обратный конвертер так же нужен. Тупым реплейсом дело не ограничится - кода больше, ошибок, как следствие, гораздо больше.
Если хранить в БД html-коды, то без обратного конвертера вполне можно обойтись, имхо. Вот прямой коныертер и валидатор (парсер) можно делать сколь угодно мощный, и.к. он будет относителдьно редко использоваться - только при создании сообщений и только админами-модераторами, имеющими доступ к расширенным опциям форматирования текста. А обычные юзеры могут удовольствоваться простым конвертером-валидатором, т.к. доступные им опции форматирования могут быть сильно ограничены.
Давайте определимся для начала, про который говорим HTML. ... Есть HTML как средство полностью видимое пользователю...
Говорим про html c ограниченными функциями, только для форматирования текста сообщений, т.е некие html-коды аналогичные bb-кодам. Естественно, эти html-теги форматирования видны пользователю при создании и редактировании сообщений, также как видны ему и аналогичные теги bb-кодов. Например,
Я за вариант хранить в базе исходное сообщение (совершенно безразлично что это будет, подмножество HTML или BB), рендер этого сообщения - в мемкэше.
Уточните, что хранить в БД. Голый текст сообщения с некими метками или же текст сообщения, отформатированный, с тегами bb- или html-кодов. Имхо, есть только два варианта, нормальных, либо хранить в БД текст с bb-кодами, либо текст с html-кодами форматирования.
Про сам парсер (рендер) здесь речи не идет, речь о том, когда его запускать а когда нет. Если запускать только при создании и редактировании сообщений, то это гораздо меньшая нагрузка на сервер ина систему, чем постоянный запуск парсера при любом просмотре сообщений.
Фильтровать и валидировать bb- или html-коды (теги) форматирования надо только при создании и редактировании сообщений. А это процедура гораздо более редкая чем массовый просмотр сообщений.
если допустим поменяются какие-нибудь стили или разметка, то что делать будите, с разметкой которая в бд?
Встречный вопрос. Что будете делать в аналогичном случае, если форматирование текста сообщений хранится в БД в bb-кодах?
Сугубое имхо. Разметка отформатированного текста сообщений (кроме заголовков этих сообщений, которые подобным образом - через bb- или html-коды - вообще не форматируются) не имеет особого отношения к стилю самого сайта (блога, форума и т.д.).
Ведь эта разметка отдана на откуп юзеру, на его усмотрение. И потому она может быть совершенно любой. Свободу юзера при этом определяет или создатель сайта или админ, эта свобода зависит исключительно от состава опций панели инструментов формы редактирования сообщений. А состав этих опция для админов и модераторов может быть один (обширный) а для рядовых юзеров другой (минималоьтный, например только B, I, U, quote, code, url - без цветов).
Здесь состав таких опций для рядовых юзеров довольно богатый...
Вопрос - как повлияли мои упражнения со здешними довольно богатыми опциями bb-кодов для юзеров на общий стиль форума? Имхо - почти никак. Они повлияли только на стиль моего сообщения.
vanicon пишет:
Скорость да наверное возрастет
Не только в скорости дело. Появляется возможность исключить процедуру (довольно затратную по ресурсам сервера) парсинга сообщений при их простом просмотре огромной массой посетителей форума. Если запрос на просмотр сообщений одновременно подают 200-300 посетителей, и для каждого надо запускать процедуру парсинга - это тяжелый случай. А если парсинг не надо при этом запускать, а просто взять сообщение из БД и отобразить для посетителя - это гораздо легче.
хранение HTML в Бд как минимум будет занимать больше места.
А насколько больше? Сам объем форматирования (в bb или в html) по отношению к объему текста не так уж и велик, имхо. Ну несколько увеличится объем форматирования в html по сравнению с объемом оного в bb - ничего страшного. На то она и БД, чтобы расплачиваться некоторым несущественным увеличением своего объема для создания удобства и увеличения скорости работы движка, плюс снижения нагрузки на сервер при отображении сообщений. Значительного снижения, поскольку сообщения, отформатированные и хранимые в БД в html представлении парсить при отображении практически не нужно.
caballero пишет:
вообще, когда я писал свой форум - такая мысль была но отказался от нее, к сожалению не помню почему.
Точно не уверен, но вроде бы в SMF сообщения в БД хранятся с HTML-форматированием.
Все - не может быть решено. Эта проблема продолжает обсуждаться на разных ресурсах, и единого мнения не сложилось. Кто-то отстаивает работу с bb-кодами, кто-то с html-кодами.
По поводу возможности записи значений атрибутов html-тегов без кавычек - это тоже интересный вопрос. В HTML5 это вполне допускается. Часто это во многом упрощает работу парсера.
А продуктивных мыслей нет? Нет никакого "форума разработчиков", есть обкатка движка в экстримальном режиме на бесплатном хостинге. И скоро этот движок оттуда будет снесен. И какой смысл пиарить то, чему суждено исчезнуть? Просто сейчас там в тестовом режиме обкатываются и определенные решения по парсингу, о которых говорится в теме. Т.е. кое-что можно посмотреть и пощупать руками в реальной работе. Остальное - в теме. Меня вопросы темы интересуют гораздо больше, чем ссылка на рабочий пример. Ссылку могу хоть сейчас убрать, если публике не нравится.
Насколько я понимаю, на этом форуме, также как и на FluxBB, в БД хранятся сообщения, пропарсенные при создании и отформатированные в bb-кодах. Значит, проблема аналогичная. При каждом просмотре таких сообщений не только участниками форума, но и любыми случайными посетителями, которых в десятки раз больше участников, такое сообщение надо доставать из БД, парсить его из представления в bb-кодах в html-представление, и генерировать страницу с сообщением уже в окончательном html-представлении. А это изърядная нагрузка на сервер при относительно плотной посещаемости форума.
Цель. Сбор информации, обсуждение и подготовка обзорной статьи о парсинге сообщений в html-кодах и в bb-кодах.
Название статьи: "Принципы парсинга сообщений. Применение html-кодов и bb-кодов".
Аннотация. Принципы парсинга сообщений в блогах, комментариях и на форумах. Парсинг с применением html-кодов, достоинства и недостатки. Парсинг с применением bb-кодов, достоинства и недостатки. Преимущества парсинга при создании сообщений над парсингом при отображении сообщений (при генерации страницы с сообщением). Преимущества и недостатки хранения в БД текста сообщений, форматированного в bb-кодах и текста сообщений, форматированного в html-кодах. Возможность оптимизации форматирования текста в html-кодах за счет записи значений атрибутов html-тегов без кавычек.
Рассматриваемые вопросы
* Парсинг сообщений в bb-кодах.
* Хранение сообщений в БД с форматированием текста в bb-кодах.
* Парсинг сообщений в html-кодах
* Хранение сообщений в БД с форматированием текста в html-кодах.
* Возможности и ограничения оптимизации форматирования и парсинга текста в html-кодах за счет записи значений атрибутов html-тегов без кавычек.
Текущая ситуация. Проблемы и решения
На текущий момент форматирование и парсинг текста сообщений в блогах, комментариях, на форумах и т.д. в bb-кодах весьма популярно,. В частности, парсинг bb-кодов довольно хорошо отработан на форумном движке FluxBB последних версий. При этом в БД хранится текст сообщений, отформатированных в bb-кодах. Такой подход имеет ряд ограничений и недостатков. Например, необходимость парсить сообщения (преобразовывать из представления в bb-кодах в представление в html) при каждом просмотре сообщения. Это может довольно серьезно нагружать сервер хостера . В то же время, хранение в БД соощений, отформатированных в html-кодах, избавляет от необходимости парсить такие сообщения при их просмотре (отображении). Однако, парсинг таких сообщений при их создании и редактировании существенно сложеннее парсинга в bb-кодах. Кроме того, хранение в БД сообщений, отформатированных в html-кодах обладает ощутимой избыточностью, по сравнению с хранением в БД сообщений, отформатированных в bb-кодах. Определенным образом упростить операции с сообщениями в html-кодах может определение правил, по которым возможна запись значений атрибутов html-тегов, используемых для форматирования, без кавычек. При этом ощутимо упрощается парсинг таких сообщений. Но и, соответственно, появляются некоторые ограничения форматирования, поскольку запись значений атрибутов html-тегов без кавычек не всегда допустима. Насколько серьезны такие ограничения - предстоит выяснить при обсуждении темы. Мне представляется, что при грамотном подходе эти ограничения на 95% можно обойти, получая при этом доволльно мошный и богатые возможности форматирования текста сообщений в html-кодах. Со всеми преимуществами такого подхода.
PS. На этом форуме, как я наблюдаю, создание сообщений также происходит с форматированием в bb-кодах.
Есть скажем 3 кнопки на сайте, которые по нажатию пропадают.
Стоит вопрос: можно ли сделать так чтобы 1 пользователь мог нажать только на 1 кнопку?
Типовая задача голосовалки. Для идентификации неавторизованного юзера (гостя) есть куки и сессии, при этом в общем случае, вряд ли такого юзера можно иначе уникально пометить кроме как кукой. Можно определять IP и прочие данные гостя и хранить их в таблице БД, а потом сверять по этим данным.
Говорят везде, что все это включено в денвер.
Если есть денвер, если ли смысл от всего выше перечисленного?
В Денвер включены сервер Apache и сервер MySQL, на последнем можно отрабатывать в локале под виндой разнообразные запросы SQL. Денвер легко ставится и настраивается под виндой, если надо с чего-то начинать новичкам - то с Денвера легче всего.
Но Денвер - это практика отработки в локале в винде различных SQL-запросов. А теория SQL - это отдельная темы, это надо в инете ресурсы различные просматрвать. Плюс надо освоить хотябы основы реляционной теории баз данных, хотя бы по относительно простым статьям.
В рунете по SQL есть хорошие ресурсы, в поиске легко находятся. На примере официальной документации по MySQL многое можно освоить. Плюс - ресурсы на английском, без этого нет программиста. (Добавление)
esterio пишет:
Вот я ненавижу PhpMyAdmin и пользуюсь ломаным Navicat-ом
Да я тоже этот PhpMyAdmin, особенно последних версий, не очень люблю. Но знать его приходится, т.к. этот PhpMyAdmin практически как стандартный сервис почти на всех хостингах стоит, а на бесплатных хостингах только он и стоит. Кстати, дамп и рестор с небольшими БД через него легко очень делается.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 48
