Re: Re: Config class

<rashid@ds.pg.gda.pl> wrote : > excuse me for using your thread, but i have some things to point out about > this class, so maybe it`s a good place for it: > - why in all get/set methods key address is splitted in two parts > (path+name)? wouldn`t it be easier for developers to use one full path? > class should split this internally imho > - i find $data array construction quite confusing. using flat array to > reflect something that isn`t flat at all (think of xml as a base container, > not ini files) isnt good idea in my opinion. i know that its > class inside > structure and it probably doesn`t matter for end user, but as i was > thought - code should always reflect reality, not create one. my proposition > is to use nested arrays to store configuration data - just to make things > clearer. or maybe performance was the most important thing when you decided > to use flat arrays? of course additional ticks for going through array would > be needed. > - does anybody (except me :)) use wddx container? if not than it wouldn`t be > bad idea to withdraw it from cvs. my goal was to create container that > supports writing and block nesting at the same time (no matter how bad it > looked in files) - if you are going to implement this features generally (or > did i get this thread wrong?) - there is no need to leave wddx container. > when i was writing wddx container there were no signs of full feature xml > container in near future. > > btw - don`t get mad if my questions were answered somewhere in deep past, i > wasn`t here when you were making first drafts, so just give me some hints > why is that made in this or other way :) Hi Robert, I didn't write the config class in the first place so I can't give you any info regarding its design and why it was made this way. I do agree with most of your remarks and I will take them into account when I will redesign the class. It is still work in progress but I am afraid that backward compatibility will not be possible. As I said before, I need a config file parser and writer class that can deal with different formats, this will be the purpose of this class. I am also trying to make it keep track of the parsed config files layout so that when the data are written back, comments and layout are preserved. Some containers like db or xml don't need this feature. This will be specified in the container class. I don't think this class will be very fast and should in no way be required on every page to parse a configuration file, except if it is a custom format. This class should be used when it is necessary to read/modify/create a configuration file. For config files, I agree with what Chuck said, using regular php variables is the best way to go for php scripts. One can also use php .ini files as there is a parse_ini_file function in php but this is probably less efficient. As of wddx, it must be parsed using the wddx extension of php but this is also less efficient than regular php vars or even php globals. In general, the Config class is not meant to parse a config file on every script request as I think it's done in the Data_Object package but should be used to manage configuration files when needed. I see it more like something that could be used in a webmin-like application. Thanks for your comments, Bertrand Mansion Mamasam