Теги форумов: PHP, авиабаза

2004-12-22, Balancer: К сожалению, отсутствие rewrite-техонлогий на многих сайтах и, самое печальное, примитивность поисковых систем, у каждого объекта должен быть строгий и единственный адрес. Что требует выделения одного из родителей объекта в качестве главного, а остальных - в качестве второстепенного. Нужно подумать на счёт категорий. С одной стороны, хочется, чтобы это был предельный примитив для упрощения жизни и пользователей и авторов ("Космос", "Компьютеры", "Юмор" - понятно, что объект может входить сразу в несколько категорий), с другой - хочется конкретики ("Компьютеры -> Интернет", "Компьютеры -> Программы"). Но на предельном уровне это та же система родителей. Так что тут нужно не балансировать как-то, а сразу определиться с пределами. Не знаю, в общем. Надо думать.

2004-12-22, Balancer: Двуслойный драйвер 1. Драйвер непосредственной работы с БД. Обеспечивает низкоуровневые действия, связанные с выдачей/записью заданных параметров объектов. "Дай мне число просмотров объекта 12345". "Запиши заголовок объекта 7890". 2. Драйвер обеспечения работы с CMS, обеспечивает высокоуровневые запросы к драйверу 1. "Дай мне список цепочек родителей объекта 5678". "Сделай бекап требующих этого полей объекта 34567". Разграничение доступа на уровне объектов, но не параметров. Доступ по умолчанию + модификаторы. Разграничение доступа на уровне операций. Кому какие тэги можно использовать. Какие поля менять.

2004-12-09, Genocide: Hi ALL !!! Немного предложений. По списку: 1. Провести голосование "Кому какая логическая структура удобнее и больше нравиться - древовидная или линейная, с пунктами: а. Древовидная (я хожу и на ВИФ и на Авиабазу) б. Линейная (я хожу и на ВИФ и на…

2004-10-22, Balancer: Потроха смотрел в 4.5 (сегодня слил), но только в сорцах. Форум последней версии смотрел на нынешнем drupal.ru - 4.4.2 Сам ставил для тестов 4.4.0 - на этом сервере Drupal был весьма нетороплив даже в сравнении с iPB-движком форума И намного медленнее…

2004-10-20, Balancer: Так как форум - это только часть всей системы, то неплохо бы было и идеи по CMS отдельно собирать. В частности - в Wiki. Хочется реализовать распределённую Wiki-систему. Чтобы сервера могли обмениваться списками/заголовками статей и, т.о., чтобы имелись бы межсайтовые автоссылки, навигация и т.п. Но пока нет чёткого представления, как это сделать оптимальнее.

2004-10-18, kv75: … Мне кажется, пока надо писать на PHP, а там будет видно. Кто-то уже высказывал мысль, что при большом желании всё можно и переписать, сделав разные варианты. Но на сегодняшний день, если учитывать цели, PHP мне кажется наиболее адекватным вариантом. ……

2004-10-07, Balancer: Сейчас имеется полнофункциональная CMS (система управления контентом), частично интегрированная с форумом iPB. Особенности: Релизована объектная модель на базе MySQL. Движок выполнен в виде внешнего драйвера (хотя и весьма массивного) на двух уровнях: MySQL-интерфейс для простейших операций (вставить значение, извлечь значение и т.п.) - объём файла всего 258 строк. Фактически, переход на иные способы хранения (другие БД, plain/text файлы и т.п.) выполняется, в основном, его заменой. чтобы проще ссылаться - имя файла DataBase.php Интерфейс моей CMS - надстройка над DataBase.php, реализующая объектную модель. Т.е. для каждого объекта (страница, картинка и т.п.) есть набор атрибутов (ширина картинки, дата модификации страницы, URL страницы, описание, список родителей, список детей и т.п. - всего уже десятки параметров). 464 строки. Требуется доработка, т.к. есть несколько прямых запросов к MySQL минуя DataBase.php. Имя файла - DataBaseHTS.php (HTS - давнее обозначение моего формата разметки, ещё когда он был…

2004-10-07, Balancer: Начну пока рассуждать в конкретных направлениях. Итак, мысли сейчас такие. Каждый объект системы, будь то страница сайта или топик форума может быть (задаётся или разработчиком, в случае страницы, или администратором, в случае форума) разного формата. Например, статику проще всего класть в HTML, динамику - в PHP и т.д. По умолчанию для большинства нужд предполагается статический HTML. Всё же, разница в быстродействии, даже при использовании всевозможных акселераторов, порой, идёт на порядки. Особенно, если сервером стоит не Апач, а что-то более скоростное. Встаёт вопрос адресации этих страниц. Их где-то нужно хранить. Если для форума это не проблема, каждый топик выделяется номером, по этому номеру его и хранить можно, для скорости, ещё и порезав, скажем, на подкаталоги - site.ex/forum/0/1/2/5/012507/ то для сайта всё становится несколько сложнее. Во-первых, я сторонник "человекопонятных URL" ("ЧПУ"). Т.е. чтобы не ничего не значащие цифры в идентификаторе, а нормальное название, пусть и латиницей (хотя было…

2004-10-06, Balancer: Сабж? Если задействовать JavaScript для include изменяющихся частей форума, то можно сделать страницы статическими. Точнее - сделать аналог статического HTML-кеша. - Перехватываем обработчик 404-й ошибки. - Если страница форума не найдена, скрипт её генерит и отдаёт. - Если найдена - то загружается статический HTML. - Вся динамика (если вообще будем делать, например - список просматривающих топик) подключается через JavaScript - Периодически старые кеши чистятся Кстати, если сразу продумать, то всю эту машинерию можно попытаться реализовать на уровне скинов. Т.е. кому со статикой не интересно возиться, будут пользоваться "PHP-скинами". Кому важна производительность - тот задействует "HTML-скины" или "SSI-скины".

2004-09-06, slipstream: Хм, скорее тогда три ошибки, или два пожелания и одна ошибка: 1) Неудобно, когда внутри bb-тага "code" срабатывают bb-коды и автозамена ссылок на их заголовок :-/ 2) Неудобно, когда внутри bb-тага "url" срабатывает автозамена ссылок на их заголовок. 3)…

2004-08-08, Balancer: … Конечно - движка. Для пользователей (и модераторов, администраторов) остаётся всё прозрачно. … Это отдельная таблица в БД. И, как я писал выше (читай внимательнее) для поиска по тексту недоступно. Только по заголовкам. А полнотекстовый поиск - или…

2004-06-06, Balancer: Также напомню, что есть форум тэги Авиабазы , где я понемногу начал набивать описания тэгов