Вопрос, скорее всего, разрабу. Хотя, если кто сталкивался, напишите свои мысли. У меня пока ничего более лучшего, как писать параметры своего модуля где-нибудь в ХМЛ файле в голову не приходит. Суть в чем. Прочитал эту статью http://imperacms.com/articles/modules/hello-world.htm - вроде все понятно. Теперь вот такой вопрос: как реализовать сохранение каких-либо полей в базу данных? В том же модуле из примера "helloword". Допустим, задача стоит не посто чтобы вывести из полученного $_POST имя, веденное юзером. Необходимо, чтобы при вводе имени оно записывалось куда-либо, как макимально лучший вариант - в базу данных. Так, при следующем открытии админки - мы получаем это же имя уже проставленное в поле "Ваше имя". Надеюсь, понятно объяснил :-)

Если можно, хоть вкратце - как реализовать в HelloWorld.admin.php несколько полей, которые будут сохраняться и, самое главное, их сохраненные значения можно было бы использовать уже в HelloWorld.php.

Допустим есть следующая форма, чья разметка генерируется методом createForm модуля. Сейчас я не забочусь проверкой XSS-инъекций и не суть важно строение формы, думаю, для примера 4 полей достаточно. Когда пользователь запостит форму, мы хотим извлечь ее поля и сохранить, чтобы использовать через время.

public function createForm ( $values ) {
    return '<form method="post">
                Поле 1: <input name="param1" type="text" value="' . $values[1] . '" />
                Поле 2: <input name="param2" type="text" value="' . $values[2] . '" />
                Поле 3: <input name="param3" type="text" value="' . $values[3] . '" />
                Поле 4: <input name="param4" type="text" value="' . $values[4] . '" />
                <input name="posted" type="submit" value="Сохранить" />
            </form>';
}

Вариант 1: сохранять в настройках сайта.

Простой пример чтения предыдущих состояний полей формы и перезапись на новые, если форма только что была запостчена. Переменная $prefix использована как защита от затирания чужих настроек.

public function fetch ( & $parent = null ) {
    $prefix = 'MyModuleName_';

    $values = array();
    $values[1] = $this->settings->get($prefix . 'param1');
    $values[2] = $this->settings->get($prefix . 'param2');
    $values[3] = $this->settings->get($prefix . 'param3');
    $values[4] = $this->settings->get($prefix . 'param4');

    if ($this->request->getPost('posted')) {
        $values[1] = $this->request->getPost('param1', $values[1]);
        $values[2] = $this->request->getPost('param2', $values[2]);
        $values[3] = $this->request->getPost('param3', $values[3]);
        $values[4] = $this->request->getPost('param4', $values[4]);

        $this->cms->db->posting_setting($prefix . 'param1', 'коммент о настройке', $values[1]);
        $this->cms->db->posting_setting($prefix . 'param2', 'коммент', $values[2]);
        $this->cms->db->posting_setting($prefix . 'param3', 'коммент', $values[3]);
        $this->cms->db->posting_setting($prefix . 'param4', 'коммент', $values[4]);
    }

    $this->body = $this->createForm($values);
}

Вариант 2: сохранять в xml-файле.

Для примера пусть это будет файл config.xml и располагается в папке модуля.

if ($this->request->getPost('posted')) {
    $values[1] = $this->request->getPost('param1', $values[1]);
    $values[2] = $this->request->getPost('param2', $values[2]);
    $values[3] = $this->request->getPost('param3', $values[3]);
    $values[4] = $this->request->getPost('param4', $values[4]);

    $this->xml->exportFile(dirname(__FILE__) . '/config.xml', $values, 'configuration');
}

Ещё можно хранить в джсоне.

$fn = dirname(__FILE__) . '/config.js';
$js = json_encode($values);
file_put_contents($fn, $js);

И читать из джсона.

$fn = dirname(__FILE__) . '/config.js';
$js = file_get_contents($fn);
$values = json_decode($js, true);

2Тарен:

Бесусловно, можно хоть через файлы пихать, хоть через XML. Меня больше интересует вопрос как отловить момент постинга из админского модуля.

2Разраб:

То есть, как я понимаю, постинг формы тоже проходит через функцию fetch()?

$this->settings->get($prefix . 'param1')

Получение данных (насколько я понял из таблицы settings самой базы данных). Судя по всему один параметр - название извлекаемого свойства.

$this->cms->db->posting_setting($prefix . 'param1', 'коммент о настройке', $values[1])

Записать данные в базу данных в таблоицу settings. параметров по всей видимости 3 - название свойства, коммент, значение свойства. А какой тип записываемого свойтсва? Я имею в виду TEXT, VARCHAR или ???

ЗЫ. Кстати, удивлен, почему разнесены два по сути родственных метода get и posting_setting(why not put?) в разные классы. Вернее, зачем отделили пут от гета?

Вариант 2 - выглядит проще, но он явно хуже. Например, при переезде сайта, наужно не забыть кроме дампа базы посливать все ХМЛ-ы. А это всегда забывается, патаму ша сисадмины разгильдяи и пьют пиву на работе.

У нинiшньому виглядi Impera CMS геть не пристосована для легкої сторонньої доробки адмiнiстративної частини сайту php модулями. Маю на увазi фрiланс програмування за допомогою зручних i простих системних викликiв, яке не вимагає вiд найманця детального вивчення всiх особливостей кожного виклику.

Звiсно ця CMS вiдноситься до потужних систем з рiзноманiтним iнтегрованим функцiоналом, але поки що це CMS одноосiбного програмiста. Нi в якому разi вона не має якостей, сприяючих фрiланс розробцi, не говорячи вже про колективну, командну чи партнерську. Тому мiстить безлiч методiв, розрахованих лише на того, хто у подробицях знає нутрощi скрипта i мислить як той же розробник CMS. Адже кiлькiсть методiв та властивостей дорiвнює 1000, а то i бiльш, якщо порахувати в усiх класах об'єктiв. Мабуть така чисельнiсть стала наслiдком спроб передбачити всi випадки в межах технiчних завдань по кожному модулю.

Вiдволiкаючись вiд мiркувань про правильне написання, бiльшiсть методiв безумовно можна вважати гарними з боку мети, що досягається їх кодом. Проте розкиданi по файлах абияк. До того ж названi iнколи незрозумiлим чином.

Тому я не радив би викорустовувати цi методи, наприклад $this->cms->db->posting_setting() i тому подiбнi, де вiдразу помiтнi розбiжностi з традицiйними формами iменування, якщо на таке використання немає вагомих пiдстав. А краще на якийсь час знайти альтернативний пiдхiд, щоб пiзнiше скористатися правильними методами, котрi напевно з'являться в системi виходячи з останнiх приємних новин.

По-перше, помiтно перенесли увагу на проблеми стороннiх доробникiв. Це витiкає з того, що бiльше почали слухати побажання програмiстiв i код системи з наступним оновленням кожного разу стрiмко змiнюється. По-друге, у ядрi з'явилися директорiї objects/.any-models, objects/.db-models, objects/.mod-models, objects/.ref-models, де зiбранi унiверсальнi класи, якi тепер легко викорустовуються i написанi у традицiйнiй манерi дружнього програмування. Наразi положення справ слiд чекати змiниться до кращого.

Але зараз наявних методiв унiверсальних моделей, також чисельнiсть цiх моделей, поки що недостатньо для ефективного вживання класiв. Наприклад objects/.any-models/Settings.php має всього один метод get, а чи буде в ньому щось ще, коли та в якому виглядi, одному боговi вiдомо. Тому раджу чекати i не лiзти без потреби в пекло постiйного рекодiнга свого модуля, щоразу як тiльки CMS оновилась.