Сохранение параметров плагина в БД

Вопросы
Здравствуйте, собственно вопрос.
При разработке собственного плагина хотелось бы сохранять некоторые его параметры в хранилище т.е. в БД
Есть ли такая штатная возможность или для каждого плагина необходимо делать свою таблицу с параметрами?

19 комментариев

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

И да придется таки писать такой функционал самому, т.к ls штатно берет параметры из конфига в папке плагина config
avatar
Тогда другой вопрос. Кого нибуть интересует такая функциональность ШТАТНО встроенная у ЛС
avatar
Ну так как никого не интересует?
avatar
Конкретизируйте вашу цель. Создайте issue на гитхабе если хотите коренным образом внести такую возможность. Там уж разработчики подключатся может быть, в любом случае останется открытое предложение, а тут большинство сидящих пользователи которые не вкурсе о чем вы.

Но почему нет, сделайте комит, а там уж оценят
avatar
Приведу пример: Есть плагин «Гороскопы» у него есть возможность выбирать из 7 разных типов гороскопов. Причем выбирать через админку (т.е. не правкой конфигов). Теперь я хочу чтобы этот ВЫБОР был сохранен. Соответственно либо в конфиге (неудобный способ) или в общей таблице ПАРАМЕТРОВ модуля (удобный способ).
В данный момент это делается через создание собственной таблицы с параметрами. но согласитесь создавать целую таблицу ради к примеру 1-го параметра — не экономично.
Вот как-то так
avatar
по вашему нужно нафигачить параметры всех плагинов в одну общую таблицу? как вы видите поля такой таблицы?
avatar
а вы предлагаете каждый раз залить и менять ручками параметры?
avatar
вы только идею предложили и кого без деталей она должна заинтересовать?
avatar
Ну к примеру поля таблицы могут выглядеть так:
modulename varchar(),
paramname varchar(),
paramval varchar()
Циферки можна потом расставить
в Engine внедрить методы:
GetParam, SetParam, EnumParam
Которые и будуть выбирать соответствующие параметры из БД автоматически подставляя в поле modulename — название модуля из которого вызываются.
Как то так
avatar
В aceAdminPanel в модуле Admin есть такие методы:
public function SetValue($sKey, $sValue)
public function SetValueArray($aValueSet)
public function GetValue($sKey, $xDefault = null)
public function DelValue($sKey)
public function GetValueArrayByPrefix($sPrefix)
public function DelValueArrayByPrefix($sPrefix)

С их помощью вполне можно сохранять, восстанавливать, удалять любые значения. Чтобы избежать каких-либо возможных конфликтов, ключи сохраняемых параметров должны быть в стиле конфига движка, т.е. примерно так:
function SavePluginParam($sPlugin, $aParams) {
  foreach ($aParams as $sKey=>$sVal) {
    $this->Admin_SetValue('plugin.' . $sPlugin . '.' . $sVal);
  }
}
$aParams = array('param1'=>123, 'param2'=>'abc');
SavePluginParam('myplugin', $aParams);

И в базе у нас сохранятся значения:
'plugin.myplugin.param1'=>123
'plugin.myplugin.param2'=>'abc'

И доставать их можно либо по одному, либо все вместе по префиксу:
$sParam1 = $this->Admin_GetValue('plugin.myplugin.param1');
$aParams = $this->Admin_GetValueArrayByPrefix('plugin.myplugin.');
avatar
Спасибо, но это получеться отдельный модуль. А я говорю о штатной функциональности движка.
Всетаки мое мнение что такая функциональность должна быть штатно в движке
Вот как она выглядит в очень МИНИМАЛЬНОМ виде(Патч для текущей версии ЛС):


diff --git a/config/config.php b/config/config.php
index 0d7c5b1..9ab2c0c 100644
--- a/config/config.php
+++ b/config/config.php
@@ -280,6 +280,8 @@ $config['db']['params']['dbname'] = 'social';
 $config['db']['table']['prefix'] = 'prefix_';
 
 $config['db']['table']['user']                = '___db.table.prefix___user';
+$config['db']['table']['moduleparams']                = '___db.table.prefix___moduleparams';
+
 $config['db']['table']['blog']                = '___db.table.prefix___blog';
 $config['db']['table']['topic']               = '___db.table.prefix___topic';
 $config['db']['table']['topic_tag']           = '___db.table.prefix___topic_tag';
diff --git a/engine/classes/Engine.class.php b/engine/classes/Engine.class.php
index 790f51f..7b04b1e 100644
--- a/engine/classes/Engine.class.php
+++ b/engine/classes/Engine.class.php
@@ -950,6 +950,19 @@ class Engine extends Object {
 			//throw new Exception("(autoload '$sClassName') Can not load CLASS-file");
 		}
 	}
+
+	public static function setParam($obj,$parname,$parvalue) {
+		$oConnect = Engine::getInstance()->Database_GetConnect();
+		$sql = "INSERT INTO ".Config::Get('db.table.moduleparams')." (modulename,paramname,paramvalue) values (?,?,?)";
+		$oConnect->query($sql,get_class($obj),$parname,$parvalue);
+	}
+
+	public static function getParam($obj,$parname) {
+		$oConnect = Engine::getInstance()->Database_GetConnect();
+		$sql = "SELECT paramvalue FROM ".Config::Get('db.table.moduleparams')." WHERE modulename=? AND paramname=?";
+		$aRow=$oConnect->selectRow($sql,get_class($obj),$parname);
+		return $aRow['paramvalue'];
+	}
 	
 }
 
diff --git a/install/sql.sql b/install/sql.sql
index 6f08620..a961497 100644
--- a/install/sql.sql
+++ b/install/sql.sql
@@ -145,6 +145,7 @@ CREATE TABLE IF NOT EXISTS `prefix_country` (
   KEY `country_name` (`country_name`)
 ) ENGINE=InnoDB  DEFAULT CHARSET=utf8;
 
+
 -- --------------------------------------------------------
 
 --
@@ -789,3 +790,9 @@ ALTER TABLE `prefix_user_field_value`
 --
 ALTER TABLE `prefix_vote`
   ADD CONSTRAINT `prefix_topic_vote_fk1` FOREIGN KEY (`user_voter_id`) REFERENCES `prefix_user` (`user_id`) ON DELETE CASCADE ON UPDATE CASCADE;
+
+CREATE TABLE IF NOT EXISTS `prefix_moduleparams` (
+  `modulename` varchar(60) NOT NULL,
+  `paramname` varchar(60) NOT NULL,
+  `paramvalue` varchar(60) NOT NULL,
+) ENGINE=InnoDB  DEFAULT CHARSET=utf8;
avatar
Использование предлолагаеться так:
$this->oEngine->setParam($this,"kuku","kuku");
print $this->oEngine->getParam($this,"kuku");
avatar
Ну, мало ли чего должно быть в штатной функциональности! Тут сколько людей, столько и мнений. Но я лично никому не рекомендовал бы лезть непосредственно в движок, если не собираешься дальше самостоятельно его поддерживать и развивать, а рассчитываешь просто на обновления.
avatar
В engine такое добавлять не стоит, лучше создать отдельный модуль, например, Storage
avatar
Ну я какбы скрипт накатал. Я думаю его можно в любой модуль втулить.
О своем мнении по поводу размещения этой функциональности в штатном ЛС или в его дополнениях — я высказал.
Стоит ли добавлять это — вопрос к разработчикам.
avatar
вопрос не в этом, а в том, что это плохой пример, который могут увидеть другие начинающие разработчики и использовать этот патч
avatar
Тогда звиняйте, за пример он просто был сделан для того чтоб показать что ничего страшного нет в том чтобы добавить эту функциональность — нет
avatar
2 раза нет это какбы опечатка. Но надеюсь суть предложения понятна.
К стати у меня еще вопрос по типам топиков но это вопрос уже для отдельного поста. Куда бы лучще его запостить?
avatar
Я — выкрутился, теперь вы выкручивайтесь © к\ф День радио
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.