модуль для создания файла настроек

[glebushka]

Я тут неспеша свою CMS пописываю.
Возникло понимание, что настройки пользователь должен иметь возможность редактировать не только в текстовом файле, но и через веб-интерфейс.
Проблема в том, что хочется оставить этот файл модулем Перл. Так как файл сам по себе редактируется редко, а зато используется при каждом запуске. Поэтому парсить каждый раз по меньшей мере глупо.
Ещё проблема, в настройках используются не только обычные переменные, но и массивы, и хеши, и массивы хешей. Есть ли готовый модуль, или придётся сочинять самому?

[Phoinix]

glebushka
IMHO выбирать прийдется только 1\\одно из двух;
Мне проще делать дамп хеш массива переменных и массивов (что, впрочем я обычно и делаю)...
Но тогда отпадает возможность редактирования в текстовом режиме.

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

[NeoNox]

Врядли именно такой есть.
http://search.cpan.org/search?query=Config&mode=all
Мне нравится Config::IniFiles, но он не подходит под твое описание.

[2NetFly]

А почему бы не воспользоваться кэшированием? Хранишь настройки в любом удобном для редактирования формате, а потом кэшируешь их в произвольную структуру Perl и подключаешь посредством require.

[Phoinix]

2NetFly

а потом кэшируешь их в произвольную структуру Perl

Можно этот момент пояснить?

[2NetFly]

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

Если я правильно понял вопрос %)

[Phoinix]

2NetFly
AFAIK слово "кешировать" имеет несколько другое значение.
Я захожу в ini файл нотепадом, редактирую, сохраняю, а теперь мне еще и скрипт запустить для создания дампа хеша?

Может быть, только вот насколько показывает практика, пользователи зачастую забывают о более мелких вещах, чем это...

[2NetFly]

Этот процесс можно автоматизировать. При кэшировании (создании дампа структуры) запоминаем дату изменения исходного конфигурационного файла. Этой информации достаточно для того, чтоб узнать, обновился ли конфиг и, в случае необходимости, перечитать его и обновить кэш. Мне достаточно даты, но я уверен, существуют более "правильные" способы узнать, нужно ли обновлять кэш.

[Green Kakadu]

glebushka:
Ещё проблема, в настройках используются не только обычные переменные, но и массивы, и хеши, и массивы хешей. Есть ли готовый модуль, или придётся сочинять самому?

есть Data::Dumper :)

[glebushka]

1. Какой модуль использовать для сохранения структуры и последующего извлечения? Data::Dumper, Storable
2. Насколько я понимаю, любое из этих решений будет работать медленнее простого перл-модуля (я подключаю его через use).
И мне тоже нравится Config::IniFiles (спасибо NeoNox что в своё время ткнул носом в этот модуль:)). Думаю производительность будет одинаковая.
Просто хочется сделать правильно. Если отношение частоты изменения настроек к их чтению 1 к миллиону, то логичнее оптимизировать операцию чтения.

ЗЫ. Ну с кешированием тут всё понятно, в крон подвесить задание, что если время изменения конфигарционного файла больше времени изменения кеша. То запускать скрипт, который исправит эту незадачу.

[2NetFly]

Data::Dumper подготовит для тебя структуру, которую ты можешь сохранить в файл и подключить используя require, или же считать из файла в переменную и сделать eval. В первом случае никаких потерь производительности не будет.

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

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

[glebushka]

2NetFly, не для того я переписывал код под mod_perl, чтобы терять скорость на парсинге конфигов:)
Кривизны моих рук достаточно, чтобы свести преимущества мод_перл на нет, даже без парсинга конфигов:)
Вообщем понял, пошёл читать доки по Data::Dumper.

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

Какая разница ООП или нет? В любом случае запускать по крону нужно. (проверять каждый раз при запуске скрипта не самая лучшая идея в смысле оптимизации).

[2NetFly]

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

[Green Kakadu]

glebushka:
 Какой модуль использовать для сохранения структуры и последующего извлечения? Data:umper, Storable

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

[Green Kakadu]

glebushka:
ЗЫ. Ну с кешированием тут всё понятно, в крон подвесить задание, что если время изменения конфигарционного файла больше времени изменения кеша. То запускать скрипт, который исправит эту незадачу.

а зачем? имхо если у тебя под mod_perl все висит, то в случае изменения конфига достаточно сам конфиг перезагрузить. и забить на тех недоумков, которые будут "править в блокноте", потом загружать на сервер и после чего забудут нажать кнопку "reset\'
если нормально все будет правиться через веб конечно

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