Тема о CMS (размышления об изъезженном)

[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 существует, это я сам прекрасно знаю, но мой путь был выбран осознанно.

 

[флоппик]

Порой я страдаю идеотизмом (идеализмом) и все время пинаю себя за что-то. Хочу сделать максимально гибко и быстро, в то же время деление по файлам моих событий модуля меня всегда смущало. Насколько это оправданно с точки зрения производительности. С одной стороны я понимаю, что файл в 5кб будет занимать меньше места в памяти, нежели куча актов в одном файле.

Золотое правило оптимизации знаешь? «Не гадай, а сделай замеры»

 

[igortik]

Золотое правило оптимизации знаешь? «Не гадай, а сделай замеры»

Соглашусь.
Логически - здесь нечего мерять, а и так ясно, что будет быстрее. Вопрос более к знатакам низов - насколько оправдан мой подход полной дифференциации, т.к. у него есть как плюсы (скорость), так и минус (при большом кол-ве актов файлов становится много), с другой же стороны - это дает возможность работать разным людям над разными акатми.

Опять запутал сам себя... ))

 

[newARTix]

igortik
никто не парится с количеством файлов. На нормальных хостингах стоит APC или аналоги.

 

[igortik]

Да, еще в соседней теме прозвучало, что НЕ есть хорошо использовать global $somevar.
Можно аргументы в студию почему это мнение имеет место? Например, случай для $lv (lang vars системы + модуля, собравшись в один массив отдаются модулю через ф-ию mod('some_module','some_action') выражением global $lv).

Ведь с точки зрения передачи данных ф-ии не совсем удобно кормить ей 20 аргументов, ведь куда проще и красивее объявить нужные данные через global, или я не прав?

p.s. фактически, в обоих случаях будут отданы ссылки, ну а если захотим в модуле уже изменить массив, то это уже иная песня...

 

[igortik]

igortik
никто не парится с количеством файлов. На нормальных хостингах стоит APC или аналоги.

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

Но логику не проведешь, 100кб в памяти будут занимать больше, чем 5кб, + нагрузка на проц (по факту интерпретации файла), а также разбор кода куда нагляднее.

P.S. Есть еще доводы в минус абсолютному разделению?

 

[флоппик]

igortik
никто не парится с количеством файлов. На нормальных хостингах стоит APC или аналоги.

Еще как парятся, ибо много lstat() не очень хорошо. Правда, 5.3 снял часть этой проблемы, ибо там появился realpath_cache

 

[флоппик]

Внезапно знакомый сообщил страшную вещь: «Realpath cache is disabled if safe_mode or open_basedir are set.»

 

[igortik]

Внезапно знакомый сообщил страшную вещь: «Realpath cache is disabled if safe_mode or open_basedir are set.»

Так все же склоняешься к разделению?

 

[igortik]

Уважаемые, ЧЕМ плохо повсеместное использование global $somevar в методах?

 

[флоппик]

А мы подождем, пока на этот вопрос ответит наш гуруPHP - HraKK

 

[igortik]

А мы подождем, пока на этот вопрос ответит наш гуруPHP - HraKK

Он хоть и профи, но говорит много
Если не сложно - док в студию в отрицание выражений типа global $var; нужно в реальном времени

 

[HraKK]

но говорит много

Специально для тебя ограничусь одной фразой в этой теме.

Уважаемые, ЧЕМ плохо повсеместное использование global $somevar в методах?

Тем что их можно повсеместно менять.

 

[igortik]

Тем что их можно повсеместно менять.

Ну это ясно. Даже говорить не о чем.
Потому я и приверженец объявлять жизненно необходимые данные константами, а global использую для улучшения читабельности кода и вменяемо осознаю, что мне нужно просто прочесть, а что обновить.

Пожалуй, если это единственный минус, то я на нем спотыкался раз 5 от силы за все время программирования...

 

[igortik]

Специально для тебя ограничусь одной фразой в этой теме.

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

Как раз твое мнение и вменяемую критику хотелось увидеть в этой теме.

 

[HraKK]

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

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

class Router
{
    static public $controller;
    public function route()
    {
        Router::$controller = 'a';
        User::getAuth();
    }
}

class User
{
    static function getAuth()
    {
        Router::$controller  = 'b'; // счастливого дебага, с*ки.
    }
}

Если б не было статики выглядело бы это таким образом.

class Router
{
    protected $controller;
    public function route()
    {
        $this->$controller = 'a';
        if( false == User::getAuth() )
        {
            $this->controller = 'b';
        }
    }
}

class User
{
    static function getAuth()
    {
        if( ... )
        {
            return false;
        }
    }
}

Вот где логику легче понять не зная как работает все приложение?

 

[AmdY]

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

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

 

[igortik]

Всегда чищю зубы кирпичем для улучшения сияния зубов, иногда выбивает зубы, но спотыкался на этом раз 5 от силы.

Намек ясен.
Как тебе такой вариант:

1. программист должен осознавать что делает и как делает.
2. Я говорю про константы для важнейших данных, которые определяются еще в логике

А теперь рассмотрим ситуацию:

1. Ты передаешь методу переменную в качестве аргумента, она становится локальной и ты спокойно выводишь ее.
2. Ты объявляешь переменную через область видимости global $var и также выводишь ее

Оба варианта делают одно - используют переменную внутри метода для чтения.
Какие здесь аргументы в минус global ?

P.S. Я спорить не буду. но хотелось бы еще услышать про минус такого подхода за пределами "пузырей" на счет переназначений.

 

[igortik]

Читаю Ваши мнения.. просьба подождать мой коммент.

 

[HraKK]

Обновил, просмотри мой пост