Разработчикам на заметку: автозагрузка моделей

[aVadim]

Движок строится на парадигме MVC, поэтому контроллер получат данные из модели, например, так:

$this->model_account_address->getAddress(...);

Но перед вызовом модели нам необходимо ее загрузить (зарегистрировать) в регистре:

$this->load->model('account/address');

Но зачем опять городить лишний код, если такие мелочи, как загрузка нужной модели, можно делать автоматом? Что я и сделал.

В классе Registry я изменил метод get():

public function get($key)
    {
        if (isset($this->data[$key])) {
            $obj = $this->data[$key];
        } else {
            if (preg_match('/^model_([a-z0-9]+)_(.+)$/', $key, $matches)) {
                $model = $matches[1].'/'.$matches[2];
                $this->get('load')->model($model);
            }
            $obj = (isset($this->data[$key]) ? $this->data[$key] : NULL);
        }
        return $obj;
    }

И... Все! Теперь я могу не задавать явно загрузку модели вызовом $this->load->model(), а сразу обращаться в контроллере к методам модели через $this->model_account_address, и если эта модель еще не загружена, то она автоматом подгрузится в момент обращения.

[UncleAndy]

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

В данном конкретном случае мы имеем удобство программисту, но лишний preg_match на каждый запрос. Рекомендую поизучать вопрос о тяжести запросов. Работа с регулярными выражениями - один из самых тяжелых после работы с БД (существуют даже аппаратные ускорители для этого). Так что я категорически против такого. Лучше поставить 10 закрузок модели чем вносить тормоза регулярными выражениями.

[aVadim]

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

А я исхожу из другой парадигмы. Популярность любого движка находится в прямой зависимости от скорости и удобства разработки под этим движком. "Тормоза" в разработке однозначно являются тормозами для развития движка.

В данном конкретном случае мы имеем удобство программисту, но лишний preg_match на каждый запрос.

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

Рекомендую поизучать вопрос о тяжести запросов.

А я в курсе, не первый год програмлю. И я вовсе не сторонник пихать их везде и всюду без надобности. Но до фанатизма тоже не стоит доходить. Сто тыщ регулярок при загрузке страницы - это не очень гуд. А несколько десятков сравнительно простых запросов - это вовсе не проблема.

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

Ну, если будет время, можно, конечно, тесты провести, насколько десяток подобных регулярок тормозят. А так это сугубо теоретический спор

[UncleAndy]

А я исхожу из другой парадигмы. Популярность любого движка находится в прямой зависимости от скорости и удобства разработки под этим движком. "Тормоза" в разработке однозначно являются тормозами для развития движка.

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

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

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

А я в курсе, не первый год програмлю. И я вовсе не сторонник пихать их везде и всюду без надобности. Но до фанатизма тоже не стоит доходить. Сто тыщ регулярок при загрузке страницы - это не очень гуд. А несколько десятков сравнительно простых запросов - это вовсе не проблема.

Ну, если будет время, можно, конечно, тесты провести, насколько десяток подобных регулярок тормозят. А так это сугубо теоретический спор

Да в общем да. Пока не будет принято решение о полноценном форке, думаю, такие правки не имеют особого смысла.

У меня тоже есть очень много идей по работе движка с базой. Но я понимаю что на данном этапе вреда от них больше чем пользы.

[Yesvik]

Ну, если будет время, можно, конечно, тесты провести, насколько десяток подобных регулярок тормозят. А так это сугубо теоретический спор

Да что там тестить? Есть куча мест где тормоза на порядок круче регов. Например кешер с glob'ом - это не просто тормоз, это якорь закопанный в землю...

[aVadim]

Да что там тестить? Есть куча мест где тормоза на порядок круче регов. Например кешер с glob'ом - это не просто тормоз, это якорь закопанный в землю...

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

[aVadim]

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

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

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

public function get($key)
    {
        if (isset($this->data[$key])) { 
            // если объект (в т.ч. и модель) уже загружен, то он просто достается из массива
            $obj = $this->data[$key];
        } else {
            // если объекта нет, то проверяем, не модель ли это
            if (preg_match('/^model_([a-z0-9]+)_(.+)$/', $key, $matches)) {
                // да, модель, и мы делаем попытку ее загрузить
                // при этом механизм загрузки точно такой же, 
                // как при вызове непосредственно из контроллера
                $model = $matches[1].'/'.$matches[2];
                $this->get('load')->model($model);
            }
            // и еще раз пытаемся вынуть модель из списка загруженных
            // если выше попытка загрузки прошла успешно, то возвращаем модель
            // если нет - NULL
            $obj = (isset($this->data[$key]) ? $this->data[$key] : NULL);
        }
        return $obj;
    }

Пока не будет принято решение о полноценном форке, думаю, такие правки не имеют особого смысла.

Да я и не прошу вносить это в движок. Я понял уже, что на текущем этапе ocStore - это пока лишь локализованная сборка. Но, возможно, мои советы будут интересны тем, кто не ждет у моря погоды, а кромсает движок самостоятельно, как я.

У меня тоже есть очень много идей по работе движка с базой. Но я понимаю что на данном этапе вреда от них больше чем пользы.

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

[Yesvik]

Я в первые дни знакомства с OpenCart посмотрел профайлером что к чему и мне стошнило, взял банальный CacheLite с раскидыванием по разным дирам - земля и небо... только с удалением там немного через банальное отверстие получается.

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

[Sammy95]

preg_match здесь вполне можно заменить на explode.

[aVadim]

preg_match здесь вполне можно заменить на explode.

Не-а, если будет, скажем, model_tool_seo_url (или, например, какой-нибудь model_tool_yet_another_cool_class), то банальная замена не прокатит. Как вариант, можно, поставить explode и добавить дополнительную логику для "склеивания хвостов", но не уверен, что прям резко в быстродействиии мы выиграем, а вот читаемость кода ухудшится.

Да и вообще, страхи относительно регулярок обоснованы там, где выражения какие-то очень уж заковыристые, и/или количество итераций с ними - сотни тысяч. А десяток-другой регулярок с довольно простыми выражениями погоды не делают совсем. Хотя, бесспорно, там, где можно заменить регулярку строковой функцией без ущерба для кода - это нужно делать.

[Sammy95]

Не-а, если будет, скажем, model_tool_seo_url (или, например, какой-нибудь model_tool_yet_another_cool_class), то банальная замена не прокатит. Как вариант, можно, поставить explode и добавить дополнительную логику для "склеивания хвостов",

Зачем склеивать хвосты, если их можно не разбивать. См. параметр limit: http://php.su/functions/?explode

[Yesvik]

Зачем склеивать хвосты, если их можно не разбивать. См. параметр limit: http://php.su/functions/?explode

Согласен.

$parts = explode('_', $key, 3);
if (sizeof($parts) == 3 && $parts[0] == 'model') {
    $model = $parts[1].'/'.$parts[2];
    $this->get('load')->model($model);
}

Но как по мне - регулярка в данном месте логичнее. А преждевременная оптимизация - зло.