Page 1 of 1
Code Library
Posted: Mon Aug 13, 2007 10:20 pm
by iknownothing
Hey Guys,
Not sure if this is exactly in the right spot, but it seems somewaht relevant to the Forum Title.
I'm thinking of creating a code "library" for all the code I use, and will use on regular occasions. PHP, HTML, Javascript etc will all go in separate folders in the library, and each snippet will have its own file.
To make my job easier, I'm thinking of creating a Master Configuration file for each website I'll do in the future, with uncommon variable names linking the Configuration file to files withing the library eg. $fromConfig_database_user (being the username string in the database connection snippet).
So, if I have a file named index.php for example, I will have a list of include/require functions at the very top, first pulling the Configuration file, and then the snippets afterwards. Only necessary snippets will be included, so the Configuration file will hold unnecessary variables in some cases.
Does anyone think this is a good idea to speed up development time, or does it seem impractical and could cause problems later down the track?
Thanks.
Posted: Tue Aug 14, 2007 3:14 am
by onion2k
Function libraries that you can copy between sites to give you a standard set of functionality are a great idea. That's very much worthwhile.
Configuration files that you copy around seem to be a less good idea. The configuration (database user, passwords, etc) should change between sites otherwise it's a whopping great security risk; if one site were hacked the intruder would have access to all the sites. A standard template that you fill in with all the details for the site is a good idea though.
I'd also say that things like $fromConfig_database_user should actually be in a registry object or at least defined as constants.
Posted: Tue Aug 14, 2007 4:05 am
by CoderGoblin
OK can't remember where but there has been arguments on this forum about the use of ini files for declaring things. If so you may want to look at
parse_ini_file.
Personally I prefer a combination of things... Constants or Registry Pattern if possible for some things, INI files for those settings which are often updated and change between each appliation/installation which may be modifed by someone who hasn't got a clue about php.
Posted: Tue Aug 14, 2007 4:48 am
by iknownothing
onion2k wrote:Configuration files that you copy around seem to be a less good idea. The configuration (database user, passwords, etc) should change between sites otherwise it's a whopping great security risk; if one site were hacked the intruder would have access to all the sites. A standard template that you fill in with all the details for the site is a good idea though.
I'd also say that things like $fromConfig_database_user should actually be in a registry object or at least defined as constants.
Are you saying the variable names themselves are a security risk, or their values? Because their values would be changed per site. I'll take your advice on the Registry Object/Constant too.
Thanks
Posted: Tue Aug 14, 2007 8:36 am
by s.dot
iknownothing wrote:onion2k wrote:Configuration files that you copy around seem to be a less good idea. The configuration (database user, passwords, etc) should change between sites otherwise it's a whopping great security risk; if one site were hacked the intruder would have access to all the sites. A standard template that you fill in with all the details for the site is a good idea though.
I'd also say that things like $fromConfig_database_user should actually be in a registry object or at least defined as constants.
Are you saying the variable names themselves are a security risk, or their values? Because their values would be changed per site. I'll take your advice on the Registry Object/Constant too.
Thanks
As long as the values are changed, I don't see any security risk.
Posted: Tue Aug 14, 2007 9:02 am
by onion2k
iknownothing wrote:Are you saying the variable names themselves are a security risk, or their values? Because their values would be changed per site. I'll take your advice on the Registry Object/Constant too.
I mean the values. For example, using the same database user between separate sites is a very bad idea.
Posted: Tue Aug 14, 2007 1:13 pm
by Christopher
I think my main reaction against config vars with names like "$fromConfig_database_user" is that they imply a bunch of global vars named to avoid clashes. I would prefer to have a Value Object name $Config injected somehow into the code, because it is clear what it does and where it is from.
Posted: Thu Aug 16, 2007 8:52 am
by thinsoldier
My main reaction against config vars with names like "$fromConfig_database_user" is that they're too damned long to type.
I've been using $CONFIG['whatever'] for a while now but I'm switching to $conf->whatever. Much shorter.
Posted: Thu Aug 16, 2007 3:41 pm
by Begby
thinsoldier wrote:My main reaction against config vars with names like "$fromConfig_database_user" is that they're too damned long to type
It sounds like you need an IDE that does autocompletion. Its somewhere between heaven and bliss to be able to name stuff whatever you like and not have to worry about typing it all in.
Posted: Fri Aug 17, 2007 6:31 pm
by Ollie Saunders
On my IDE I press t followed by return to produce $this->_. I can write things like $this->_somePropertyName in 4 keystokes. It's very cool.
Posted: Fri Aug 17, 2007 6:33 pm
by superdezign
ole wrote:On my IDE I press t followed by return to produce $this->_. I can write things like $this->_somePropertyName in 4 keystokes. It's very cool.
I soo want that. Mine has AutoComplete, but I have to define it all manually. :-/
Posted: Fri Aug 17, 2007 7:04 pm
by Ollie Saunders
The t => $this->_ bit was a manual define. It's also got these things called templates that rule. In particular I've got this one called prop (short for property) that looks like this:
Code: Select all
/**
* @var ${TYPE}
*/
private $_${LC_NAME};
/**
* @return ${TYPE}
*/
public function get${UC_NAME}()
{
return $this->_${LC_NAME};
}
/**
* @param ${TYPE} $new${UC_NAME}
* @return ${CURRENT_CLASS}
*/
public function set${UC_NAME}(${TYPE} $new${UC_NAME})
{
$this->_${LC_NAME} = $new${UC_NAME};
return $this;
}
${END}
Basically if I'm inside a class I type prop, hit return and then specify the type, tab, name beginning with lowercase, tab, and name beginning with uppercase. So for instance if I type
Code: Select all
class Foo {
prop<return>
Bar<tab>zim<tab>Zim<return>
And I end up with
Code: Select all
class Foo
{
/**
* @var Bar
*/
private $_zim;
/**
* @return Bar
*/
public function getZim()
{
return $this->_zim;
}
/**
* @param Bar $newZim
* @return Foo
*/
public function setZim(Bar $newZim)
{
$this->_zim = $newZim;
return $this;
}
}
Posted: Fri Aug 17, 2007 7:38 pm
by superdezign
The most tedious part of OOP...

I wonder if mine can do that...