Page 1 of 1
COnfig data
Posted: Mon Aug 28, 2006 8:44 pm
by alex.barylski
There have been many disscussions on this subject...
I've always advocated GLOBALS were fine...I've seriously never experienced a problem with them, maybe through diligence and discipline or possibly through pure luck or maybe just never noticed a bug caused by GLOBALS...
Regardless, the verdict is in...most people prefer to use OOP to encapsulate their global data, using a registry, etc...
So I have decided to switch my ways...besides...I can see the benefits using a registry would offer, I just never changed that part of my development because until latelyrecently...I never programmed on multiple developer projects...
So...
I ask, but again...
What technique do you use to store GLOBAL data or config data???
Do you store your configs in a XML file and load that data into a class, etc...
If you can *find* any of the previous disscussions and care to share those...that would be awesome too...I can't find any...

Posted: Mon Aug 28, 2006 9:09 pm
by feyd
Posted: Mon Aug 28, 2006 9:12 pm
by alex.barylski
LOL
Cool cool...you can lock this thread if you like...
I seriously did look, but obviously not that hard
Sorry

Posted: Mon Aug 28, 2006 10:10 pm
by alex.barylski
Bump: Just to bring to everyones attention...
Config data...is it mutable? Why not?
I change my environment variables occasionally...but maybe it's outside the domain of a config class?
Perhaps we should differentiate the two?
1) Configuration data is static and likely set at install time and therefore immutable
2) Settings are primarily static, but capable of change and reflected system wide
Should there be a distinguised difference between the two???
If yes, does anyone have other naming suggestions?
Posted: Mon Aug 28, 2006 10:17 pm
by feyd
I don't see a point in making a distinction between install-time settings and other settings. Can [you] give a more thorough example why?
edit: darn this here engleesh.
Posted: Mon Aug 28, 2006 10:33 pm
by RobertGonzalez
Hockey, can you keep from bumping an hour after a post. This is bad juju on these boards.
Posted: Mon Aug 28, 2006 10:38 pm
by alex.barylski
feyd wrote:I don't see a point in making a distinction between install-time settings and other settings. Can to give a more thorough example why?
Wll I'm looking at Zend Config class right now...and it's awesome, but doesn't allow write...from what I can tell...
So when that config data changes...am I supposed to manually modify my INI using Notepad or do I write a PHP script into my backend which updates the data...
So it occured to me, that maybe a Config class with read/write operations might make sense, but it seems...most cinguration classes don't handle both just INPUT, which is silly considering the amount of work it would require to implement a write solution...
Besides, I don't think it's so much out of the domain of config data...as to me it makes sense...perhaps config data is read only because it's meant to remain static through the history of the application's life time...when changed dier consequences will ensue...but applications settings change frequently, but are still persisted for the period of time an end user chooses...
I wanted to know if anyone else consider them seperate entities, so I could perhaps rename my class from config to settings, to more accurately reflect it's purpose and intent

Posted: Mon Aug 28, 2006 10:41 pm
by alex.barylski
Everah wrote:Hockey, can you keep from bumping an hour after a post. This is bad juju on these boards.
Sorry dude...however:
Non-trivial posts are not considered bumping. A bump post found in violation will be deleted, and you may or may not recieve a warning. Persons bumping excessively be considered as spammers and dealt with accordingly.
What I bumped for, I wouldn't consider trivial...it's still under the context of config but it included a poll as well...
Anyways, my aopoligies again

Posted: Mon Aug 28, 2006 10:47 pm
by feyd
Just don't include the "bump" stuff.. if it's non-trivial, it's not a bump.
As for the topic at hand now, I consider it ridiculous to put configuration data on a pedestal by saying "it will not change in this application's life time" or something similar. I write my code with the full knowledge that all configuration data can and will be changed by someone at some point. Even during the life time of an installation. Therefore I write logic to understand those changes so there is no breakage because Johnny decided to change the database password or whatever "Zend" considers config data.
Sorry, I can't place Zend on a pedestal either.
Posted: Mon Aug 28, 2006 10:56 pm
by alex.barylski
I'm not putting anyone on a pedestal...Except maybe myself

But i'm no narcassist(sp?)
Anyways, I think your missing the point...my point wasn't to *not* have my code react properly when conf data changes...thats just silly...as obviously most data will change, database passwords, etc...
But perhaps it's worth considering that there may be data that should be immutable???
That wasn't the question though, my question was more focused on what developers thought about the possibility of the two and if data is mutable, as I would tend to agree BTW...why don't these config classes support read *and* write???
Seems silly to imlement that functionality anywhere else...as most classes support the idea of containers or data stores or drivers, etc...
So if you hard coded an INI write in your admin scripts...but later decided to switch your config from INI to XML...Beeeeeeeeeeeeeeeeep!!! there goes your application...
So IMHO using a single centralized class for both READ/WRITE makes sense???
Just curious, as I've designed a class which does both...and as I look aorund at others...I see most only implement read functionality...which just seems kinda odd to, for the reasons mentioned above
Cheers

Posted: Mon Aug 28, 2006 11:16 pm
by feyd
I can only imagine that they would consider all/most configuration data immutable. Considering I stand in contrast to that, I can't tell you why they would do such a thing, so uhm.. yeah.
Posted: Tue Aug 29, 2006 12:13 am
by darodesign
I've got my own Configurattion class, which stores the Configuration Variables to an MySQL Database, and an XML file.
To use my Config in Smarty ( Templates ), i've assigned the opject to the template.
I'm doing very easy scripts with that script.
Posted: Tue Aug 29, 2006 2:58 am
by Jenk
I have separate classes for the use of config data in every day life, and then a second class used for changing the config data.
The 1st is just like Zend's idea of a config/settings class - only output no input (read, no write.) The 2nd is both input and output (read and write.)
Posted: Tue Aug 29, 2006 3:22 am
by onion2k
Settings that are supposed to be changed by the application installer/developer/maintainer .. put them in an ini file and make people use Notepad to change them.
Setting that are configured by the admin/users go into a database with a shiny PHP interface.
Posted: Tue Aug 29, 2006 8:40 pm
by alex.barylski
onion2k wrote:Settings that are supposed to be changed by the application installer/developer/maintainer .. put them in an ini file and make people use Notepad to change them.
Setting that are configured by the admin/users go into a database with a shiny PHP interface.
There you go...with that definition...you've made it clear IMHO that there should be a concrete definition of both terms...
I personally say config data is volatile...of course it can change...whereas maybe, there are times when application setup values shouldn't be changed by anyone but an automated script which knows best...
So I say, there is a difference between the two...and proper definitions should ensue...
