I recently wrote a post about three PHP mistakes that can give you a bad headache. The blog readers commented even more mistakes, and there was a whole new article on another site with 8 mistakes of their own!
This post is dedicated to the mistakes my readers posted in the comments, and lastly linking to the other mistake article.
Imagine the following: you have some form elements that need to render themselves. You have saved them in a database, as your users must be able to modify the forms. You have a bunch of different kinds of elements: a text field, a longer textarea field, maybe a field used for entering dates.
How would you determine, which kind of a field your code needs to render? The simple choice would be to put them in a switch block, which looks at the type of the element, and maybe calls some method based on that.
But what if you need to add a new element type? What if you need to add 10 new element types? The switch will get very long and that’s not good for readability of the code. But with some smart use of classes and polymorphism, we can easily solve this problem
As a part of my work at The Group, I’ve been developing a suite of applications for them. As most web applications do, these applications have to store their user data somewhere – in a database.
As you may guess, the user’s password has been stored as a hash. As a part of some new developments, we are moving our user data into a new table structure, and among that, we are introducing stronger sha1 hashes with salt.
But how do you convert an md5 hash into a sha1 hash?
I’ve been asked things like “how do you find time to blog?” and “how do you find things to blog about?” a few times lately…
First an announcement: During 2008, CodeUtopia had about 120 000 visitors! I think that’s amazing, and I want to thank everyone who has been reading the blog. I’m going to try and keep posting interesting things for you to read this year too. :D
Now, to the post: Back in 2003 I wrote a game called GroupFight. The idea started as a joke, so don’t expect anything very amazing ;)
In the game you are a fighter, who fights against monsters and gains experience, levels up and so on. Let’s look at it a bit more after the jump
If you have written a model layer which separates database access from the rest of the code, you probably know that you may end up with lots of methods like findByName, findByTitle or such, for cases where you want to find records based on specific criterias.
You could also use arrays, for example findBy(array(‘title’=>’something’)). However, these are easy to type wrong, and you don’t get any validation that the value you’re passing can even exist to begin with.
You could also use your model objects as search “criterias” – A bit similar to how Propel handles criterias, but not as nearly as complex.
Here are some PHP mistakes I’ve encountered, which have often been very difficult to track down…
Probably all of us have used template engines in one form or another. Some might even like template engines for whatever reason, but let’s think about it for a moment: are they actually making our lives easier?
Most template engines simply wrap PHP (or some other language’s) syntax into their own syntax, and maybe they look a little bit cleaner when mixed with HTML. Some may even provide useful features like automatic variable escaping to prevent XSS vulnerabilities.
But does this actually significantly reduce the amount of code needed to write some common scenarios, or make it easier to read/manage the code?
I decided to try profiling my quiz application to see if I could speed it up. Not surprisingly, biggest performance penalties came from loading classes and Doctrine’s ORM magic.
Here are some findings on how to improve performance.
Here’s a quick tip on how to deal with configuration files when working with Subversion. This probably applies to other VCS’s too like CVS or Git.
You probably have noticed this: you have a configuration file or such, and you need to keep it in SVN, but committing it would be a problem as updating it on other machines would mean their own configurations get overwritten.
So how to solve this? Simple: Instead of storing the configuration file with its own name in SVN, rename it to something like config.base.php, and fill it with some example configuration values and commit that instead. This way each developer can simply create a copy of config.base.php on their boxes and do their own configurations there, without having to worry about an svn update overwriting their settings.