TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
Kohana_Config_File_Writer
  • Sometimes it is very convinient to store configuration in files just the same way as Kohana_Config_Database_Writer stores config in Database.

    For example in my projects it is very important to divide files from database, because some configuration should be shared by CVS with all project developers.

    So as for me it would be very useful if

    $config = Kohana::$config->load('my_group');
    $config->set('var', 'new_value');
    

    could save configuration in APPPATH in existent or new config file.

    So we (MotionToday team) created simple Kohana_Config_File_Writer that realizes this function. It is commented, well covered with unittests but I think still needs some attention.

    Actually I think that such function is quite natural, so I propose to include it in any future Kohana branch.

    If this function is really useful how can I share this work with you? Fork/pull request?

  • One of the big reasons we don't include anything like this is concurrency, a file writer just can't be reliable when multiple users are triggering writes at the same time..

    I guess there are certain cases where this may be acceptable, but I think those are somewhat limited and could easily be catered for with the Database Writer.

    Any reason you avoided the DB Writer?

  • Also - If you want it considered for inclusion, file a feature request at http://dev.kohanaframework.org with some compelling reasons to include it ;) A pull request or link to the code would be useful too considering it's already been written.

    In the meantime, You can split it out into a module for others to use..

  • Ok, thank you :)

  • Any reason you avoided the DB Writer?

    In my opinion projects usually can be divided into three logical parts:

    1. Code (PHP, JavaScript)
    2. Design (layout HTML, CSS, layout images)
    3. Content (user HTML, uploaded images)

    Code and Design parts should be stored in file system — for easy sharing between developers by CVS.

    Content — should be stored mainly in SQL Database to provide fast access.

    Actually the main reason — that sometimes changeable config should be stored in file system.

    Here are several examples:

    1. items_per_page in pagination;
    2. configurable design;
    3. finally, with File_Writer install.php would be able to set database config with some kind of UI

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion