Code Library

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
User avatar
iknownothing
Forum Contributor
Posts: 337
Joined: Sun Dec 17, 2006 11:53 pm
Location: Sunshine Coast, Australia

Code Library

Post 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.
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Post 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.
User avatar
CoderGoblin
DevNet Resident
Posts: 1425
Joined: Tue Mar 16, 2004 10:03 am
Location: Aachen, Germany

Post 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.
User avatar
iknownothing
Forum Contributor
Posts: 337
Joined: Sun Dec 17, 2006 11:53 pm
Location: Sunshine Coast, Australia

Post 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
User avatar
s.dot
Tranquility In Moderation
Posts: 5001
Joined: Sun Feb 06, 2005 7:18 pm
Location: Indiana

Post 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.
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.
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Post 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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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.
(#10850)
thinsoldier
Forum Contributor
Posts: 367
Joined: Fri Jul 20, 2007 11:29 am
Contact:

Post 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.
Begby
Forum Regular
Posts: 575
Joined: Wed Dec 13, 2006 10:28 am

Post 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.
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post 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.
User avatar
superdezign
DevNet Master
Posts: 4135
Joined: Sat Jan 20, 2007 11:06 pm

Post 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. :-/
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post 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;
    }
    
}
Last edited by Ollie Saunders on Sat Aug 18, 2007 2:57 am, edited 1 time in total.
User avatar
superdezign
DevNet Master
Posts: 4135
Joined: Sat Jan 20, 2007 11:06 pm

Post by superdezign »

The most tedious part of OOP... :-D
I wonder if mine can do that...
Post Reply