https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26790
--- Comment #18 from David Cook <[email protected]> --- (In reply to David Cook from comment #17) > > my $mq_crud_conf = Koha::Config->relative_file('mq_crud.yml'); > Oh but this wouldn't work with Tomas's ideas, which were very good. (In reply to Tomás Cohen Arazi from comment #12) > My vote would be: > - Use separate files with expected names (config.yaml, shibboleth.yaml, etc) > - No includes > - Have C4::Context->config rebuild the 'old structure we already have, and > deal with a different new handling on a separate bug (Koha::Config singleton > implementation?) > - Have a way for C4::Context->config to override any configuration if an env > variable exists. e.g. KOHA_DATABASE_NAME should override the relevant entry. What about using AUTOLOAD? my $mq_crud = Koha::Config->mq_crud(); If the "mq_crud" doesn't exist in an internal data structure, it could then do the Koha::Config->relative_file('mq_crud.yml') or looks for KOHA_MQ_CRUD in an environmental variable to load the configuration from file and then saves it. (This wouldn't use Koha::Cache at all and would require a process restart to refresh configuration like with koha-conf.xml.) The only downside of that would be that you couldn't use an env var override for lower level config... like Koha::Config->mq_crud()->destination; Although you probably could do something clever... where Koha::Config->mq_crud() returns a Koha::Config::Entry object which could use AUTOLOAD or have dynamically created methods during object creation time. There are options... which of course makes it tougher to choose. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
