Это же получение параметра, а значит и запрос в базу для их чтения. Или $this->params для всех плагинов инициализируются каким-то одним глобальным запросом? Я как-то не копал в эту сторону и не знаю, как там Joomla их подгружает, но мне это кажется нелогичным.
Хы, прикольно. А ты не знал этого? Когда ты взываешь JPluginHelper::importPlugin, выполняется вот такой код:
$className = 'plg' . $plugin->type . $plugin->name;
if (class_exists($className))
{
// Load the plugin from the database.
if (!isset($plugin->params))
{
// Seems like this could just go bye bye completely
$plugin = self::getPlugin($plugin->type, $plugin->name);
}
// Instantiate and register the plugin.
new $className($dispatcher, (array) ($plugin));
}
а в getPlugin, в свою очередь, вызывается метод _import, в котором выборка из базы трех полей folder, element и params.
К слову сказать это одна из самых существенных оптимизаций в Joomla 1.5 - раньше каждый плагин грузил свои параметры раздельно, несмотря на то, что запрос к БД все равно был для получения информации о статусе публикации плагинов. А данная реализация позволила существенно снизить нагрузку на базу. Я удивлен, что ты не в курсе этой истории, мы это много обсуждали.
Либо хранить их в отдельном файле, либо в классе определить как константы: время и период.
Оно раньше в файлах и хранилось, но были проблемы с правами доступа и прочим. Поэтому я придумал эту схему.
В таких случаях наверное лучше писать в близлежащий файл переменную без обращения к базе
Как я писал выше - так оно и было, но были проблемы с правами.
В принципе, можно в плагине вызов функции с оптимизацией делать через кэш, тогда она будет выполняться с периодичностью, равной времени кэширования. Можно пойти дальше, сделать в плагине свои настройки кэширования, и инициализировать кэш с доп. параметрами, тем самым перебросив задачу ограничения периодичности вызов на систему кэширования - она просто не будет вызывать оптимизацию, пока кэш валиден.