Flourish PHP Unframework
This is an archived copy of the forum for reference purposes

Suggestion for config files class

posted by ilo 9 years ago

Hi, first of all, I've found the kind of library I was looking for, finally, great!

I've been reading the whole documentation and playing with the demo application (northshorewebgeeks.com) and the more ready to start using flourishlib I feel, the more things I'm missing, hehe. There is one class that I've found very usefull, considering that flourishlib is just the library, and as developers we are going to reuse our own code from site to site: store site configuration in a separate file, so we can share the rest of code from site to site.

Do you think a coniguration file class fits in flourishlib? I'm not sure yet about the scope of the class (reading files, writting files also) but the interface of frequest to get the url parameters is perfect for this case - ::get($varname, $cast, $default); -.

As long as the database is only being used for real live data, things like site Title, an email address, an about paragraph or any other things could go into this file, to avoid touching several .php files when building a new site.

I'w love to work in this if you think is usefull (I'm going to write something for me if flourishlib does not include it).

I think there are two types of configuration I would normally use:

  1. Simple configuration used to bootstrap an app - such as database connection parameters
  2. More complex configuration, with a more robust editing interface, often requiring better performance

For the first, I would opt for using Yaml. For the second, I would store the configuration in a database.

I have a commercial project I've been working on that uses sfYaml and just wraps it with a lightweight class to load and save the configuration. I wouldn't be opposed to exploring something similar for Flourish.

What are your thoughts on Yaml?

The other idea that just came to my head was using fCache with the file backend, however that is not user-editable.

posted by wbond 9 years ago

Yaml is my preference to php-ini or XML.

  • much easier to read
  • multi-level (no need to simulate this like in php-inis)
posted by mblarsen 9 years ago

I agree that configuration can be splitted into 'bootstrap' and 'live' information, but seriously I doubt that any of them (considering the purpose of configuration) requires a nested multilevel schema that Yaml is able to handle not being simulated.

I see Yaml (or even XML) in the same package as MongoDB, using an structured 'fake' schema for the ORM to handle this kind of information, but I'd not introduce a new language nor dependency to just handle a database configuration, or a site's title: IMHO this is an overkilling solution.

After a quick review, the Hosting provider I use to use doesn't include the Yaml extension on PHP, so I guess a fallback solution (custom Yaml parser) would help, but the more I think, the worse I see the idea.

So, back to the 'approach', considering the use case: complex or more advance configuration (or regularly changing configuration) in my case is also going into Database, nothing more to say here, I guess. About the bootstrapping, what kind of information should be considered?

  • Database credentials
  • Templating information (location of files, images?)
  • Site information?: A title perhaps?
  • Email settings?

Read only or Read-Write class? well, actually it would be great to have full support, considering that a site can change or customize its own settings (an installer perhaps?).

I don't get the point of using Yaml for this, however I can forsee that a Class to handle the Get/Set/Other operations regardless the backend could be usefull.. What types of backend could be available? A .ini, XML or Yaml file? a Database connection?

Not sure if I'm being clear in my answer..

posted by ilo 9 years ago

I think I understand what you are saying - you are looking for a class to handle reading and saving configuration options to some backend. It seems that different people would have different preferences on what the backend would be.

In one sense, this feels like it is starting to venture more into framework-type territory. Building a configuration class that could use a database, PHP array structures, ini format, or yaml starts getting complex fast. I think I am more interested in providing tools that allow developers to pick what kind of configuration works for them and run with it. I understand that it will be more work than just dropping in a Config interface and using any backend that they choose, but it has always been my intent with Flourish to provide more of the building blocks.

Right now fCache provides a way write config options to a file in a machine readable format. fDatabase and fActiveRecord make saving options to a database easy. Something like a yaml class would make writing config files in human-readable format easy. You could use fJSON to write JSON encoded data, it just doesn't have file loading and saving facility built in.

The problem with creating a general class to use any of these is that they all just store data. To build a config class, I would be enforcing a specific structure on how config data should be stored, and building infrastructure on how to store this structure in the different backends. I almost feel like this should be a separate library built on top of Flourish and not part of the core of Flourish.

posted by wbond 9 years ago

So, I just suggested to read ini files, you pointed that Yaml could be of your interest, and I finished talking about a generic class supporting several backends.

Actually, my real purpose was to clearly separate code and configuration regardless the way the class or backend works. Having several classes for different backends or a single class is not a concern for me in this case, but finding a way to don't mix code and configuration, and make code more portable or reusable, yes, this was my concern.

So, right now I'm unsure about what approach to take :)

Thanks Wbond!

posted by ilo 9 years ago