Settings Library - Printable Version +- CodeIgniter Forums (https://forum.codeigniter.com) +-- Forum: Archived Discussions (https://forum.codeigniter.com/forumdisplay.php?fid=20) +--- Forum: Archived Libraries & Helpers (https://forum.codeigniter.com/forumdisplay.php?fid=22) +--- Thread: Settings Library (/showthread.php?tid=48892) Pages:
1
2
|
Settings Library - El Forum - 02-03-2012 [eluser]InsiteFX[/eluser] For saving arrays you could just add a text field to your table and serialize and unserialize the arrays. You can see how CodeIgniter doe's this by looking at the CI_Session class ./system/libraries/Session.php But json would also work. Settings Library - El Forum - 02-04-2012 [eluser]Mark LaDoux[/eluser] Yeah, I've been looking at that already. I've been doing some comparisons between the different methods to decide which I like better. Settings Library - El Forum - 02-04-2012 [eluser]Mark LaDoux[/eluser] New version. Actually not much changed. I have some planned changes, but I'm tired, so I didn't even work on most of what I wanted tonight. I just got done with a 10 hour shift at work. I'll work on it more tomorrow. I'm off then. I think I'll start adding version numbers and a change log to it. I also renamed the class to Setting in order to fit along with standard CI naming conventions. Tomorrow, I'll be implementing the storage of arrays into the library. I just want to take a quick notes to items that really concern me when coding those. Mainly, escaping, unescaping, null, false, true, and empty strings. @PhilTem You said that I shouldn't return false, but rather null... after examining the CI_Config library, I see that CI returns false for unset items, and I code from an aspect where false is considered the default option for enabling or disabling things. And things that would not expect true or false should test for false to see if a setting has not been configured. But yeah, I guess not everyone does it that way. However, I do not wish to vary too far from the way it's coded in the core. Especially now that I'm deferring to CI_Config for unset items. You may ask why I don't just extend CI_Config. The reason is simple, I'm worried that some of my planned changes could potentially render the output of the class incompatible in some way that I had not considered with the native CI_Config class. This way you can fall back to the CI_Config class in it's raw untouched form if you need to for applications that were not designed with this library in mind with little or no hassle. Also, CI_Config loads before almost everything, and I would lose simplicity. Well, it made sense to me anyway. It's the same reason that I don't have set adjust any settings from the CI_Config class. If you want to make a temporary setting change, you still can using CI_Config instead of Settings. Code: <?php if ( ! defined('BASEPATH')) exit('No direct script access allowed'); |