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

Во всех прошлых не устраивала структура (сложно было разворачивать кмску для новых сайтов) поэтому и советуюсь с вами, как вам такая структура кмски. Я уверен что в этой должно быть проще! (хочу узнать ваше мнение).Так же можно считать этот пост маленьким анонсом кмски.

Кмс = цмс = Система управления контетом.
В общем у меня даже не кмска, а небольшой фреймворк получается.

Сейчас немного опишу что есть в кмске, а ниже подробней о каждом пункте.

- мультисайтовость
- мультиязычность
- страницы (шаблоны)
- Виды
- модули (MVC)
- контроллеры
- модели
- & Страницы -> Виды
- библиотеки*
- хелперы*
- логи (дебаггер)
- аякс
- библиотека Котерова “DbSimple” для работы с БД.
- чпу

* - 100% точно такие же по реализации, как у CodeIgniter (Но свои)
Пожалуй это всё.

Теперь подробней обо всём

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

Мультиязычность.
Так как в скором времени предстоит работа с сайтами, которые должны быть на разных языках. Разумно включить и мультиязычность. Тут нет ничего сложно просто в папке с сайтом есть директория languages ну а в нём папки с языками. В директории с языком может быть как один файл со всеми фразами так и директории (вообщем кому как удобней тот так и разбивает), главное что нужный язык можно подключить из любого места в шаблонах (так и етсь), написав $this->lang->load('адрес файл'), а вызывать нужные фразы можно через $this->lang->имя_файла->item('фраза'); Таким способ можно подключать хоть все языки сразу.

Страницы.
Я решил их назвать так. А вообще они очень похожи на шаблоны (как у нормальных людей, или типы страниц)
Какую страницу показывать будет решать система, в зависимости от текущего юрл.
У каждого сайта есть несколько типов страниц. Вот в директории со страницами и лежат эти типы. Например (Главная страница, Новости, Статя/Статьи, Обратная связь, ...)
Страницы представляют из себя обычный html, в котором выполняется пхп код.
Чтобы страницы не были просто страницами в них можно подключать (модули, виды, языки, (на счёт моделей не уверен, но у меня нет никаких ограничений нет, поэтому думаю можно будет)). И так чтобы подключить что-то нужно написать.

- $this->lang->load('язык'); // язык
- $this->modules->load('имя_модуля'); // Модуль
- $this->view('адрес файла с видом'); // Дополнительные шаблоны.
- $this->db // Обращенее к бд.
- $this->libraries...
- $this->helpers...
- закономерность я думаю понятна.

Вот вроде и всё что мне нужно от страниц.

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

Если обращение к виду происходит от страницы, то сначала ищем вид в директории со страницей, а потом в общей др. Если обращение происходит от модуля. То сначала смотрим в директории с модулем, потом в директории со страницей, а потом уже в общей др. Виды сделаны для того чтобы исключить один и тот же html код в шаблонах страниц. Например header, footer, ну и т.д. Чтобы подключить вид необходимо напистаь
- $this->view('адрес файла'); так же есть доп. параметры в которых можно указать, чтобы система возвращала результат работы вида в виде строки или передать в вид какие-то переменные.

Модули
Модули у меня с MVC
Поэтому в модуле есть контроллеры, модели и виды.
По умолчанию если мы подключаем модуль
- $this->modules->load('имя_модуля');
управление переходит на главный контроллер модуля (он должен иметь тоже имя что и имя модуля). Ну а в контроллере уже можно подключать другие суб-контроллеры, при этом всё управление передается подключаемому новому контроллеру.
- $this->controllers->load('имя_контроллера');
Так же подключать можно модели и виды.

Библиотеки
Библиотеки это теже классы, созданные в помощь разработчику.

Хелперы
Это уже не библиотеки и не классы, это просто отдельные функции. Опять же для помощи в разработке.

Логи
Логи собираются в определенной директории выбранного сайта с именами (датой d.m.Y H:i); ну и отчётами внутри. Логируются как ошибки так и сообщения для отладки. Что-то залогировать можно след. Образом
- log_message('debug', 'текст');
ошибки логируются автоматически.
В конфиге каждого сайта можно настроить разынй уровень логирования либо в обще его отключить.

аякс
Работать с аяком можно из любого места для этого лишь нужно написать
die('содержимое, которое нужно вернуть'); кроме этого ничего лишнего отданно не будет так как используется буфферизация.

Для работы с БД я включил в набор библиотеку Котерова.
Подробней о ней можно почитать на сайте dklab.ru

Ну и кужа же без чпу. В настройках сайта нужного сайта всё это можно настроить, например можно включить опцию, чтобы добавлялся суффикс к адресу, например ('.html'); Работать с юрл можно
написав $this->uri->segment('номер нужного нам сегменты');
Вообще с классом uri много тонкостей, чтобы не сбиваться я дам ссылку на похожее описание, собственно на то что я опирался, когда писал этот класс, там есть моменты похожие http://code-igniter.ru/user_guide/libraries/uri.html

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

Теперь зачем я всё это написал, так как я уже много раз наступал на грабли (заходил в тупик), хотел бы услышать комментарии людей хорошо понимающих в этой области. И предусмотреть в системе сразу несколько разных вариантов. А не открывать их для себя при создании сайта. Что очень часто выбивает из сроков отведённых на разработку сайта.

А ещё в видах можно использовать следущее. Его не нужно воспринимать в серьёз, но да, такое в системе тоже есть.

Обращение к страницам из страниц или из видов.
$this->pages->load('имя страницы'); таким способ мы можем подключить какую-то нужную нам страницу. Например у меня была такая необходимость для одного сайта. На главной странице мне необходимо было вывести статью, которая привязана к внутренней странице. Поэтому я использовал след. конструкцию

$this->pages->load('articles', FALSE);
$this->pages->articles->modules->load('articles');
echo $this->pages->articles->modules->articles->getArticle();

На производительности это не как не сказалось, так как загрузился только каркас страницы и модуль статей. Сам шаблон страницы статей не выполнялся (false).

Фух, вроде всё объяснил, жду критики и советов.
Спасибо за внимание.

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

 но обе стороны по-своему правы

по поводу кмски/фреймворка



не похоже на лучшее решение (не в плане скорости разработки). Модель жестко привязана к модулю, а помимо того еще и к странице? Почему так?



как-то слишком длинно получается. Я бы попытался максимально уменьшить, типа i('имя_файла/фраза'), и по возможности даже i('фраза')

А кто-то вообще встречал примеры хорошей мультисайтовой цмски? Мне когда-то пришлось работать с такой самодельной цмс... Она была сделана как-то неудобно, получалось, что изменение каких-то настроек одного сайта вело к изменениям настроек на других. Шаблоны были тоже общие, и чтобы поменять шаблон для одного сайта приходилось как-то извращаться. Также при добавлении каких-то модулей на один сайт они появлялись на всех остальных. Так что советую Вам подумать над этим вопросом заранее. Вы вот писали:


А как именно это происходит? Какова структура папок сайтов, какие между ними связи и зависимости? Что происходит при конкретном запросе пользователя?

Судя по Вашим требованиям Вам стоит посмотреть фреймворк Kohana, форк CI. Там реализовано много Ваших условий.

Например, мультисайтовость можно сделать, поменяв в index.php всего одну строчку, которая указывает на папку с файлами непосредственно сайта. Структура каталогов построена так, что сама система, модули и файлы сайта расположены в разных папках, пути которым указывются в index.php.

Мультиязычность - каждая директория сайта и модуля может содержать папку с языками (i18n) с вариантами переводов (ru_RU, en_US и т.д.), вставка в код происходит так:

Этот код покажет содержимое элемента массива $lang['title'] из файла i18n/ru_RU/user.php (если русский указан в настройках, как текущий язык).

Страницы (я так понял, Вы имели в виду контроллеры) реализуются довольно обыденно, одноименными с названием контроллера, файлами в папке controllers/. По умолчанию роутинг на примере site.ru/article

Хотя есть возможность указывать свой роутинг в настройках.

Виды - в папке view/. Есть довольно интересный стандартный абстрактный контроллер Template, который позволяет указат в себе имя вида (public $template = 'view'), вызываемого (или нет, если отключить авто-рендеринг) после обращения к публичному методу контроллера. Новые виды вставляются, как

Пространство имен в видах общее, так что вывод этого дела будет представлять из себя всего лишь строчку echo $view;

Папка модуля полностью дублирует структуру папки самого сайта, разнца в том, что запрошенные контроллеры/модели/виды сначала исчутся в папке сайта, после - в папках модулей, а после объявляются в общем "пространстве имен", т.е. объявление, например, контроллера article, в модуле, а не в папке сайта, никак не скажется на его доступности из других классов фреймворка. Собственно, и настройки у модуля могут быть как свои, так и сайта, или системы в целом.

Библиотеки/хелперы реализованы также, как и у Вас, с разницей в том, что хелперы являются классами, но что мешает вызыват методы через :: ? 

Логи пишутся автоматом, можно выставлять уровень отладки, а также выводит отладочные сообщения как в лог, так и на экран.

Отделять запрос ajax от запроса браузера можно через хелпер request, а именно методом is_ajax().

А вот с БД и начинаются самые вкусности  Kohana предоставляет встроеную ORM-библиотеку, которая значительно облегчает работу с базами, и позволяет правильно построить взаимоотношения между таблицами.

Например:

Тут, думаю понятно... Если идти дальше...

Этот код, покажет нам содержание всех статей в категории с id = $params... Вот так вот.

К сожалению, по фреймворку не так много документации на русском, и не слишком многочисленное сообщество, хотя как и популярность этого фреймворка, оно растет очень быстро.

P.S. Хотел написать небольшую рекомендацию, получилась целая обзорная статья... Извините, я нечаянно 
P.P.S. C CI дело не имел. Только что просмотрел в нем структуру каталогов /system/applcation/ могу сказать, что у Kohana в папках сайтов, папках модулей и папке системы она дублирована оттуда.

Это сообщение отредактировал(а) Nergal - 26.12.2008, 05:44