igortik
Новичок
Итак, пара мыслей, которые меня вот терзают уже ни один год 
На сегодняшней день в моей CMS реализовано:
1. Есть 2 базовых понятия: система (базовый инструментарий) и приложение (например, админка, фронтенд и т.п.)
1.2. Оба понятия разграничены директориями и собственным набором логики (например, класс авторизации приложения наследует базовый класс системы для получения общих констант и прочих данных и далее использует их исходя из личной логики конкретного приложения).
2. Подтягиваются исключительно те функции и классы, которые необходимы на конкретный проход
2.1. Т.е. все ф-ии и классы разбросаны по разным файлам (существуют системные базовые, принадлежащие к приложению и принадлежащие к модулю).
Хелперы типа $inc->sysFunc(), $inc->appFunc(), $inc->modFunc() тянут соответствующие файлы.
3. Полное разделение скриптов модулей по событиям, т.е. есть, к примеру act.default.php, который хранит только то, что будет происходить по-умолчанию для конкретного модуля (act.add.php - к примеру, обеспечивает сбор данных для формы добавления записей в базу, а do.add.php добавляет).
3.1. Т.е. я логически разделил понятие "событие" на 2 составляющие - вывод данных и работа с базой.
4. URL'у уделяю большое значение
4.1. Парсинг урла происходит классом логики системы с возможностью передать управление (парсинг) главному исполняющему модулю при необходимости (так достигается гибкость и исключение регулярок на уровне апача), т.е. из строки получаем массив и последовательно разбираем без регулярных выражений каждый элемент полученного массива с целью определить директивы программы (режим (ajax, не ajax), lang, module, action, и прочие переменные типа filter/page=3;catalogue=some_catalogue/).
5. Сборка на лету CSS из всех модулей приложения в одно полотно.
6. JS также подключаются по надобности, например, при создании формы forms.js конкретного модуля будет подключен, в противном случае - нет
7. ООП реализовано слабо, только по надобности
8. Понятие "шаблон" имеет место как для приложения (разные шаблоны в нужных мне случаях) так и для событий модуля (например, для актов act.add.php, act.edit.php)
9. Система "понимает когда ей работать на максимальную подгрузку", т.е. есть 3 режима: для ajax, для полного вывода, включающего шаблонизатор и прочие хелперы, а также для событий типа do.add.php, работающих исключительно с базой и по факту выполнения, отдающие header на "перевод стрелок".
Что можете сказать на этот счет?
Порой я страдаю идеотизмом (идеализмом) и все время пинаю себя за что-то. Хочу сделать максимально гибко и быстро, в то же время деление по файлам моих событий модуля меня всегда смущало. Насколько это оправданно с точки зрения производительности. С одной стороны я понимаю, что файл в 5кб будет занимать меньше места в памяти, нежели куча актов в одном файле.
В общем, критику в студию, что касается моего подхода... может есть еще какие мысли...
Прошу Вас также проявить уважение и не плеваться в сторону, мол, куча CMS существует, это я сам прекрасно знаю, но мой путь был выбран осознанно.

На сегодняшней день в моей CMS реализовано:
1. Есть 2 базовых понятия: система (базовый инструментарий) и приложение (например, админка, фронтенд и т.п.)
1.2. Оба понятия разграничены директориями и собственным набором логики (например, класс авторизации приложения наследует базовый класс системы для получения общих констант и прочих данных и далее использует их исходя из личной логики конкретного приложения).
2. Подтягиваются исключительно те функции и классы, которые необходимы на конкретный проход
2.1. Т.е. все ф-ии и классы разбросаны по разным файлам (существуют системные базовые, принадлежащие к приложению и принадлежащие к модулю).
Хелперы типа $inc->sysFunc(), $inc->appFunc(), $inc->modFunc() тянут соответствующие файлы.
3. Полное разделение скриптов модулей по событиям, т.е. есть, к примеру act.default.php, который хранит только то, что будет происходить по-умолчанию для конкретного модуля (act.add.php - к примеру, обеспечивает сбор данных для формы добавления записей в базу, а do.add.php добавляет).
3.1. Т.е. я логически разделил понятие "событие" на 2 составляющие - вывод данных и работа с базой.
4. URL'у уделяю большое значение
4.1. Парсинг урла происходит классом логики системы с возможностью передать управление (парсинг) главному исполняющему модулю при необходимости (так достигается гибкость и исключение регулярок на уровне апача), т.е. из строки получаем массив и последовательно разбираем без регулярных выражений каждый элемент полученного массива с целью определить директивы программы (режим (ajax, не ajax), lang, module, action, и прочие переменные типа filter/page=3;catalogue=some_catalogue/).
5. Сборка на лету CSS из всех модулей приложения в одно полотно.
6. JS также подключаются по надобности, например, при создании формы forms.js конкретного модуля будет подключен, в противном случае - нет
7. ООП реализовано слабо, только по надобности
8. Понятие "шаблон" имеет место как для приложения (разные шаблоны в нужных мне случаях) так и для событий модуля (например, для актов act.add.php, act.edit.php)
9. Система "понимает когда ей работать на максимальную подгрузку", т.е. есть 3 режима: для ajax, для полного вывода, включающего шаблонизатор и прочие хелперы, а также для событий типа do.add.php, работающих исключительно с базой и по факту выполнения, отдающие header на "перевод стрелок".
Что можете сказать на этот счет?
Порой я страдаю идеотизмом (идеализмом) и все время пинаю себя за что-то. Хочу сделать максимально гибко и быстро, в то же время деление по файлам моих событий модуля меня всегда смущало. Насколько это оправданно с точки зрения производительности. С одной стороны я понимаю, что файл в 5кб будет занимать меньше места в памяти, нежели куча актов в одном файле.
В общем, критику в студию, что касается моего подхода... может есть еще какие мысли...
Прошу Вас также проявить уважение и не плеваться в сторону, мол, куча CMS существует, это я сам прекрасно знаю, но мой путь был выбран осознанно.