Code Library
Moderator: General Moderators
- iknownothing
- Forum Contributor
- Posts: 337
- Joined: Sun Dec 17, 2006 11:53 pm
- Location: Sunshine Coast, Australia
Code Library
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.
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.
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.
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.
- CoderGoblin
- DevNet Resident
- Posts: 1425
- Joined: Tue Mar 16, 2004 10:03 am
- Location: Aachen, Germany
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.
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.
- iknownothing
- Forum Contributor
- Posts: 337
- Joined: Sun Dec 17, 2006 11:53 pm
- Location: Sunshine Coast, Australia
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.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.
Thanks
As long as the values are changed, I don't see any security risk.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.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.
Thanks
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
I mean the values. For example, using the same database user between separate sites is a very bad idea.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.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.
(#10850)
-
thinsoldier
- Forum Contributor
- Posts: 367
- Joined: Fri Jul 20, 2007 11:29 am
- Contact:
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.thinsoldier wrote:My main reaction against config vars with names like "$fromConfig_database_user" is that they're too damned long to type
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
- superdezign
- DevNet Master
- Posts: 4135
- Joined: Sat Jan 20, 2007 11:06 pm
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
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:
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 typeAnd I end up with
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}Code: Select all
class Foo {
prop<return>
Bar<tab>zim<tab>Zim<return>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;
}
}
Last edited by Ollie Saunders on Sat Aug 18, 2007 2:57 am, edited 1 time in total.
- superdezign
- DevNet Master
- Posts: 4135
- Joined: Sat Jan 20, 2007 11:06 pm