Object-oriented programming gives us many new ways to create an application. It makes many things easier to do. One of these things is planning. Planning is an important and oft overlooked part of an application, but it is as essential to the success of the application as the coding of it. Just to clear the air, let me clarify that planning is not necessarily spending months of sketching diagrams before a two week project. Neither is it coming up with things as you go. But planning is a great tool that will make applications more solid, easier to build, and quicker to build.
Four Story Lean-to
I spent some time in other places of the world. One of these places was Malaysia, great country. During my visit I traveled to many of the poorer areas of the country and one particular community stands out in my mind. In Tawau, East Malaysia there was a whole subdivision of houses built out over the ocean on sticks. The houses were shacks, built with driftwood and covered with tin. The walkways between the homes were also driftwood and just nailed together in random fashion. Being five times taller and three times less skinny than the largest man there (maybe that’s an exaggeration) didn’t make me feel any more comfortable walking around out there. It was obvious there had been no master plan, no idea of how the houses would be put up. But hey, it saved on property taxes.
These homes were not built to last, nor would it be easy to add new homes to the community or upgrade existing homes. And there was definitely a lot of upgrading that could have been done! Similarly, if we try to build mansions of sticks, four story lean-tos, or even a modest home with no plan, our applications will end up looking (and working) more like the forts and tree houses my brother and I built in the field behind our house.
I think all of us have built applications like this and know the pain and the bugs and quick-fixes that need to be made for the application to even work. Even after that it doesn’t end up being something you are proud to show to others (unless, of course, it’s one of your very first applications, in which case it is amazing that you got something to work at all and you want everyone and their grandmother to see)
In addition to giving us a nicer product in the end, planning allows us to ’share the wealth’ with other programmers, so to speak. We are able to help everyone see the master plan and their part in it. We are able to have more than one developer work on it at a time. Pretty innovative idea, I know.
So how should we plan? However we want. You don’t need to use UML to plan. You don’t need systems design and analysis training. You just need to sit down with some paper and start writing (or drawing) an idea of how the application will fit together. You could even just take a moment to think it through without any writing utensil for smaller projects. We will go over how to organize, what to reuse, and what we should use while we do it (our brains).
Organize
The definition of organize as Google’ tells us is ‘formed into a structured or coherent whole; methodical and efficient in arrangement or function; arranged into definite structures.’ We need to know where things are, where they are going to be, and how to find them. We also need to know how they are going to work together. Object-oriented programming is great for this because it give us a way to plan called object-oriented design. I discussed in the previous article Thinking Object-Oriented how we can visualize systems in terms of real-world objects. This is what object-oriented design is aimed at doing. We plan out the system modeling it after the real world. We imagine our ecommerce store is a real store and plan out the system based off of how a real store works. We think of our intranet as it were the company’s actual organization and plan it out into departments with their managers and employees. We are able to plan a system much more easily because we live in the real world (well, most of us anyway) and are familiar with objects, items, things, and stuff in our everyday lives.
When we create an object we need to consider that is might be reused elsewhere. This means that it shouldn’t rely on system specific things to work, and if it does, there should be a known (and good) reason for it. This kind of separation from the environment is called encapsulation and is an excellent way to make an object reusable, as well as easier to maintain and update.
Reuse
I don’t know how many times I’ve heard ‘let’s not reinvent the wheel,’ but it’s been a lot. Many times it’s been with valid points. Many other times it hasn’t been. Let me first explain what we should reuse (and shouldn’t) then I’ll go over why object-oriented programming allows us to reuse code more easily than procedural programming.
What is a classic example of something that uses a wheel? A car. Do we ever use a wheel by itself? Not often. When we ‘reinvent the wheel’ we are recreating something that has been done by many others before. However, I would like to emphasize that it is not creating a custom application again. A car is made up of many reusable parts, but we cannot take an economy car and make a four-wheel truck with it. We should build applications with reusable parts, and if our new application is to be the same or similar to another, then we can take the old and tweak it up a bit, give it a new paint job.
The reason why I am even going over this is because of many bad experiences in the past. It seems many development teams want to try to take an existing system and create their own custom application with it. ‘Why reinvent the wheel?’ In every instance it has taken much longer to try to integrate with the existing database, to try and force the application into strange contortions, to try and add ‘a few additional features’ (which end up doubling the features) then it would have been to step back, plan out the system from scratch, and rewrite it from scratch (hopefully reusing many _parts_ or pieces of other applications).
Ok, enough with that. Why is object-oriented programming more reusable than procedural? Well, again it goes back to things being easier to think about. If you are looking to put a stick-shift into your new car, you ask for a stick-shift and you get a stick-shift as well as all that goes with it. You’ll get the numbers of the gears, the methods to shift and put into neutral, all of it. If it were procedural you would need to get each method separately (although they may be sitting next to each other) and make sure you don’t forget what and where the properties are. If you need a customer in your store you could grab it from another store. You don’t need to search for all of the parts scattered throughout the store. In addition, if you need to change the customer, you only have one place to do it. And again, it’s much easier to think about the system as objects and how you might reuse the parts.
It is much easier to find things in an organized room, and object-oriented programming provides greater organization for an application than procedural programming.
Think
Now, many who are weary about using object-oriented programming are such because they have seen horrible programming that used classes, methods, and properties. They feel their procedural programming is ten times better, and they might be right. Object-oriented programming is no magic hack. It is not a cure-all. No matter how we program, to make good programs we must use your brain. I know, I know, it sounds like too much to ask. Actually, I think all of us know we may write code without much forethought of how it needs to work or turn out. We often can make it work too, just not as well as it should.
We must think about where we are going and what we are doing when we program. Even if we don’t have a written plan, we need to think the system through before hacking away. Thou shalt not be mentally lazy is a commandment I give to us all.
I wish us all luck as we build our mansions or high-quality single family homes. If we are committed to planning we will end up with nice products in the end.
A new security magazine called [in]secure has just come out with their second issue which includes a pretty good look at PHP vulnerability containment within a shared server space (page 26). Has some good examples and is a good overview-type read.
This is the second of five articles written on object-oriented programming. These articles were originally written for jacwright.com This article was going to be entitled Conceptulizing Systems, but was changed to Thinking Object-Oriented as this title better describes the content of the article. I hope these are of benefit to you.
Real Power
One of the more difficult jumps of the several leaps and bounds from procedural to object-oriented programming is conceptualizing the system you are programming. Thinking object-oriented is the real power of object-oriented programming, and even if we always program procedurally we may already be thinking object-oriented. We need to be able to see a system, a problem, or a program in terms of objects and their relationships to one another. When we do this any program will be much more simple and easy for us to grasp. It will be easy to picture how it works in our minds.
There are three ways to think object-oriented. One way it not better then another. They are all just different and each of them is used as we start use objects appropriately. I call these three ways the Top Down approach, the Bottom Up approach, and Real World Modeling.
Top Down
The Top Down approach in object-oriented programming give us a way to see the system as a whole. We break the entire system down into related parts. The Model-View-Controller design pattern (we’ll talk about design patterns in a later article) is an example of this. It breaks the system into three parts: objects related to the business model, display objects, and objects to handle user input.
When we use the Top Down approach we need to think of how the system can be broken up into logical pieces. We can slice up the entire system like I do a pie. First I slice the pie in half, then in half again, making four pieces, then in half again. I end up with nice evenly sized pieces, something I’ve never been able to do by slicing a piece at a time. Similarly with a program or system (which might be a small part of a larger system) we break it up into larger pieces, then smaller ones, then even smaller ones, until we have pieces of a manageable size.
We can see the Top Down approach thinking with a short example. Let’s use the oh-so-common ecommerce store. If we think of the system as a whole we know there will be data to keep, store functionality, and a good looking design that we want to change once in awhile. We can break our data section down into session management and a database object. We might break our store functionality into sections like the catalog, product reviews, the shopping cart, and the checkout. We can have our display section broken down into a general template and a caching template that will cache pages for reuse (so the database doesn’t have to work so hard). We can then go over each of the functionality sections and further break them down into small pieces and objects.
Bottom Up
The Bottom Up approach does not look at the system as a whole. Instead, it concentrates on grouping related functionality together. We see functions and variables as related and so put them together into an object. Then we see objects which interact or are related and put them together into a group (called a package, usually put into the same folder etc.) We can then group those object groups into larger and larger groups until we have the whole system accounted for.
Using this approach to think object-oriented we use two different steps. The first step is grouping functionality into objects. The second step is grouping objects into groups. For step one, we figure out what goes together. This can be easy if we already group our related procedural code into files. We may have a file that contains all of our database functions in it. Instead of having all the functions there sitting in the global scope and the variables they use (perhaps a connection variable, or a record-set variable), we can group it all into a database object, with properties such as the connection reference and functions such as query or closeConnection.
The second step is similar to the Top Down approach, just backwards. Instead of breaking a system down into parts, we are building it up from the pieces we know we will have. Grouping objects into larger and larger groups until we have the whole system makes it much easier to picture the internals of a system in our mind, and how things are actually working. It also allows us and others to easily find pieces of functionality to extend or fix because they are organized into folders and files (packages and objects) in a logical manner.
Model the Real World
Finally, Real World Modeling is one of the most powerful aspects of object-oriented programming. This is making objects that you know in the real world into objects in your system. Because we all live in the real world, it is easy for others to immediately understand what an object is and does if it is based off of something real world.
A customer, shopping cart, and product in an ecommerce store are immediately recognized and their interactions between each other are understood easily, because we can see the same interaction in our daily lives. We know that there can be many products in our shopping cart. We know that each customer may have a shopping cart to put their products in. We know that customers have names and addresses, and that products have names and prices. The programmatic shopping cart however may have related functionality that a real shopping cart may not have. It may be able to tell us the total price of all the products in it, where a real cart can’t do anything but roll around (something not needed in an ecommerce store).
The first thing you might do when developing a system is to discover all the real world objects in that system. Whether it is employees, supplies, offices, text characters, documents, buttons, or trash cans, they all help us think of the system easier and model it better. We already know many of the objects’ interactions and who “owns” what (the customer owns the shopping cart and the cart owns the products). These real world objects may even be the groupings of objects instead of the objects themselves. Or they may be objects that help group others. You might have a department object with its employees and manager.
Once you have the real world objects you can then group them. The shopping cart, order, and checkout might go into the same section. You may put products and categories into the catalog group. Customers and store admin may be their own group.
Object-Oriented Thinking
Object-oriented thinking has been around even before object-oriented programming. People do it without knowing it might be called object-oriented. It helps us conceptualize a system and better grasp it. It helps us wrap our mind around a system without blowing a fuse. It makes programming easier for us and easier for others coming to our code. Object-oriented programming was created to make it easy to transfer our object-oriented thinking into code, although we can still program procedurally our object-oriented design. This is the real power of object-oriented programming.
This is the first of five articles on object oriented-programming from Jacob Wright.
An Introduction to Object-Oriented Programming will give a brief overview of why there is such a thing as object-oriented programming. Conceptualizing Systems will help us to better picture a system in terms of objects and how the relate to each other. Planning an Application will teach us the importance of planning and what we should do to plan. Creating Objects explains how the objects in our application are born, and how they should be structured. Making Objects Reusable covers some more advanced topics and allows us to reuse what we�ve already created in good ways. My hope is that these Monday morning articles will help others through the transition from procedural programming to object-oriented programming.
Why Does Object-Oriented Programming Exist?
Back in the olden-days, way back when our dinosaurs were young and our parents roamed the earth, there was programming. Yes, hard to believe it was invented by that time. Back then, things were simpler. Maybe people had to walk uphill both ways to school then, but programs were smaller, less complex. Programming languages executed line by line. They had �go-to� statements that let them go to another line for execution, and that was nice, but they didn�t need a whole lot anyway.
Industrialization came along however. Change was happening. Programs became more complex. It was hard to wrap the mind around a complex program and write it line by line. Procedural programming was born. Procedures or functions allowed a programmer to more easily conceptualize a system. It allowed them to reuse code. It was easier to program.
Object-oriented programming (OOP) came about the same way. When programs became larger and consequently more complex, it became very difficult to wrap one�s mind around them. Object-oriented programming made programming a system easier. It made life simpler again.
Function, Function, Who�s Got the Function?
Many times procedural programming is referred to as �spaghetti code.� Why is it called spaghetti code? Because there are functions being called throughout the system and we can�t know where they are coming from. If we follow the flow of a procedural program, we can find ourselves looping in and out of functions and throughout scripts very much like a bowl of spaghetti. There is not (inherently) much structure. There is not much organization. Object-oriented programming becomes more like building blocks we can build with instead of spaghetti. It provides organization and we can know exactly where a given function is. This also makes it easier to know where a bug is coming from.
What Does Object-Oriented Programming Allow Us To Do?
Object-oriented programming allows us to reuse code. It gives us a �package� of related functions and their related variables that we can pass around or reuse in other systems. These functions and variables that are all related are called methods and properties in an object. Object-oriented programming can also enable the use of complicated code by everyone. It not only ports the methods and properties together, but also allows us to use them without figuring out how they work internally.
When Should We Use Object-Oriented Programming?
Object-oriented programming was conceived to allow us to create larger projects more simply. Thus, it is very helpful in our larger projects that we do. I can also be nice in smaller projects, especially once we get the hang of it. Small projects are easily done in procedural programming though, and even once we learn how to program object-oriented we may still find ourselves using procedural at times.
Is it ok to mix objects with our procedural code? Of course! Many feel that if they are going to program object-oriented that they need to jump into the deep end and just start swimming. That is just not true. It would be much better to start using objects bit by bit, more and more, than to just not use them at all because we feel that it is too much for us. Also, for small scripts it may just be easier to do them procedurally.
So What Is Object-Oriented Programming?
Object-oriented programming is a way to think. To conceptualize a system or a program. It is not the classes, syntax, encapsulation, or other big words that we will learn about in following articles. The true purpose of OOP is the empowering it gives us to see our programs in a new light, a higher view, a clearer picture. It is hard to go back once you�ve had a taste.
Recently a very good discussion took place on the UPHPU mailing list regarding MySQL and PostgreSQL (a.k.a. pg or pgsql), the two most popular open-source database engines, and when you might want to choose one or the other for your project. Many great insights were shared, and we’re sharing some of them here, in hopes that it will help others in the future.
For many people, MySQL vs PgSQL is more of a religious question than a technical one, and there is definitely something to be said for sticking to what is already familiar to you. There are also some very good technical considerations in choosing which one is more appropriate for your application. First and foremost, both MySQL and PG are excellent relational database management systems (RDBMS), and in almost every case, either one will work great, and there is no wrong answer when asking which one you should use.
Probably the biggest and most frequently discussed differences between MySQL and PG are in features and complexity. PostgreSQL has more of both. There are many features of SQL that PG has supported for years, that are just recently becoming available in MySQL. Some mentioned in the discussion are subselects, transactions, stored procedures, contstraints, triggers, and a few other advanced SQL features. Most or all of those features are (or will be) supported in MySQL 4.0, 4.1, or 5.0, and some, like transactions, were available in the MySQL 3.23.xx releases with certain table types, like InnoDB.
Because of the complexity added to PGSQL to support those features, MySQL in its default configuration (i.e. with MyISAM tables) is generally regarded as faster than PGSQL. Because of MySQL’s different table types (which use different database engines), you can effectively “turn on” and “turn off” features like transactions on a per-table basis, which provides a significant performance improvement. Many say that when using the advanced features of MySQL (i.e. when using InnoDB tables), performance is very comparable between the two databases.
There are virtues to having a less complex feature set: Simple is easier, Simple is faster, Simple is more stable. MySQL requires less system administration to configure and maintain, and for most people, it “just works” without any real tweaking or customization. Especially when being used with PHP, this is a big advantage. Most applications written in PHP simply do not require most of the advanced features that SQL has to offer, and PG would be overkill, and that overkill comes at a price.
Many people think that they would be better off with PGSQL because someday they might need a feature that PGSQL has that MySQL doesn’t have. As with most other things, if you don’t have something specific and reasonably likely in mind already, you most likely won’t ever use those features. Another important consideration is that there are very few cases where those advanced features are truly required. Granted, sometimes a subselect may make a simpler query, but it can almost always be rewritten as a join, which usually executes faster and is about as readable as the query using subselects. Especially in conjunction with PHP, it is very difficult to contrive a situation where the lack of a particular feature makes something impossible or very difficult with MySQL where it would be much easier with PostgreSQL.
Another aspect to consider is support. MySQL has a larger user base, and is supported by more applications. In cases where there isn’t support for both of them, an application is more likely to have MySQL support than PgSQL support. When both are supported, the MySQL support is generally better tested than the PgSQL support.
If you’re trying to help a client or customer or manager decide what database should be used, marketing and branding apply. If your client has heard of individual database engines, the most likely ones they’ll know about are Oracle, Microsoft SQL Server, and MySQL. Selling them on PostgreSQL can be an uphill battle if they haven’t heard of it before, though billing it as practically “an open-source Oracle” may do the trick, and is probably relatively accurate. PgSQL is the closest free and open-source equivalent to Oracle.
For others, licensing is an important consideration. PostgreSQL is released under a BSD-style license, which allows it to be used in almost unlimited ways, including embedding in closed-source applications. MySQL is released under the GPL and under a commercial licensing policy, which requires certain applications to pay for a license if their use doesn’t comply with the GPL. The main time this matters is if it will be embedded in a proprietary application.
Administrative overhead can be one of the biggest ongoing costs of your application, so careful consideration should be used before choosing something that will require more administration. MySQL is generally considered to require less administration than PostgreSQL.
If you’re already experienced with a complex database like Oracle, and like it, Postgre will be more similar to Oracle than MySQL will. If you haven’t used Oracle, or didn’t like using it, you’ll be more comfortable with MySQL in most cases.
Many people see performance (speed) and capacity (both volume of data and volume of queries) as key factors in choosing their database. In the vast majority of cases, any performance or capacity issues you might run into will not be solvable by changing database engines between MySQL and Postgres. It is probably 100x to 1000x easier to max out your database server by running poorly optimized queries, by having a poorly laid outdatabase schema, or by having a poorly written interaction between your application and your database, than to max out your database server by actually requiring an extremely high volume of data to go in or out. By the time you reach that point, you’re more likely to be running into problems like memory bandwidth, disk bandwidth, and seek times more than problems due to (or solvable by) your database engine.
Both MySQL and PostgreSQL will eventually “hit a wall” in their performance when you get enough queries. In general, a simpler, leaner engine, like MySQL, will hit that wall later than a more complex engine. Things like replication can help with performance and query capacity issues, but once you reach a high enough rate of inserts, deletes, and updates (”write” operations) in your database, replication won’t really help much. A “read” can occur at any database replica, but a “write” has to occur at all of them. If your performance problem is due to writes rather than reads, you’re better off getting a beefier server (within reason) than using replication.
If you’re not familiar with either of the two databases, or unfamiliar with SQL altogether, learning MySQL will probably be easier for you than learning PostgreSQL. If you already know Oracle, Postgres will be more familiar than MySQL. If your development team is more experienced with one or the other, that experience will probably provide more benefit than choosing a different engine. Retraining and working in something you aren’t familiar with can be somewhat costly, and usually should be avoided where possible.
There are a lot of considerations, but here’s the bottom line: Both MySQL and PostgreSQL are extremely good and capable database servers. There are a few differences that may sway you one way or the other, and there really isn’t a wrong choice. There are times when PostgreSQL is a clearly better choice for one reason or another, and in that case, don’t hesitate to use it. Keep in mind, however, that the times when PgSQL is necessary or is worth the extra complexity are far, far, fewer than the cases where MySQL is sufficient and more appropriate.
We at UPHPU hope that this article was useful to you, and we welcome your feedback. The content in this article is due to contributions by many people, and we would most notably like to thank Ray “bigdog” Hunter, Josh “dataw0lf” Simpson, Grant Shipley, Jon Jensen, Mike Trionfo, Tyler Gee, Jeffrey Moss, and Lonnie Olsen, and Scott Hill, who started the discussion.
Cutting edge CSS? Sign me up! Stu Nicholls’s CSS Playground has some jaw dropping CSS effects up for grabs. I found ‘Fluid Drop Shadows’, ‘Recipe Filing Cabinet’, and ‘Flick Animation’ to be of particular interest. Most examples include exactly what browsers they are compliant with, as well.
This weekend, I had quite the adventure configuring Apache on my home server. My IP address happened to change, and I wanted to update my Apache httpd.conf file so that my webserver would work regardless of my IP address. I also wanted to add Virtual Hosts to my personal web sites so that my IP address would no longer be visible to visitors.
The configuration turned out to be easy. Let me cover the key parts for my Win XP Pro Apache 2 configuration with a single IP address:
Listen *:80NameVirtualHost *
The above tells Apache to serve web pages for all IP addresses on port 80and to use Virtual Hosts for all IP addresses
ServerName www.my-domain-1.com DocumentRoot "c:wwwrootfolder-1" ServerAlias my-domain-1.com *.my-domain-1.com ServerName www.my-domain-2.com DocumentRoot "c:wwwrootfolder-2" ServerAlias my-domain-2.com *.my-domain-2.com
The above tells Apache to serve web pages (on all IP addresses) fromfolder-1 where requests have my-domain-1.com or something.my-domain-1.com inthe web page. Also sets up Apache to serve my-domain-2.com documents fromfolder-2.
Presto! Now I have two domains pointing to my IP address, and apache canseamlessly differentiate between the two without knowing my IP address. Itis sort of basic, but there are zillions of ways to configure apache!
“Javascript is one of very few languages that is used less often than it is abused.” — mac newbold
A recent discussion on the mailing list (subject: “RE: Javascript form validation [was Re: Posting a form]“) prompted me to post an article about JavaScript, and how to use it appropriately. I’m not a JavaScript expert, and I don’t play one on TV. But I am versed in it and have seen a lot of good and bad things done with it. My main goal in sharing my thoughts on the subject is to help people know when and how JavaScript is the right answer, and make the world a better place. If talking about things like this can open a dialogue, that would be great, and we can get the word out to help stop people from falling into the trap. Newbies especially can benefit by finding out about the problems before they get into bad habits.
One of my biggest issues with the way people use Javascript is when they use it for validating form input. It is one aspect of the problem of using client side programming for things that can only effectively be done on the server side.
Because Javascript is run on the clientside, it is not guaranteed in any way to be run. It is insecure. It can be faked, skipped, avoided, disabled, and any number of other undesirable things. Search engines don’t run any of it either, though that doesn’t have much to do with form validation in particular. People can even make a form like yours, but without the javascript, and submit that instead of your form.
Before I go further, let me say that client side validation (and other client-side functionality) has its place. In many cases, it can make the user experience better by providing faster response than submitting the form to the server, and it can do things that the programmer thinks are helpful, like updating other fields as values are selected or entered. (Another pitfall is the programmer doing things that they think are helpful, without any consideration for the users that find the same thing very unhelpful, and weren’t given a way to disable the behavior, but that’s an article for another day)
However, because it can be easily bypassed, it is of absolutely no use for guaranteeing that the form submission meets certain criteria. The only place that can be done is on the server side, where the programmer has complete control over the data and the validation performed on it.
I’ve seen horrific things in this regard. One in particular that makes me cringe is when I saw a site that used Javascript to calculate the amount a credit card would be charged, and the server side blindly accepted whatever the javascript told it, and billed the card that amount, and considered the bill paid in full. Another javascript abuse I saw used a form that did not have a valid action, so the form didn’t have anywhere to submit to, and by means of javascript, validated things and proceeded to (incorrectly) fashion a GET string, then set the page’s location to that string. I’ve seen others that do a pretty good job in the javascript of validating things, but when the page was submitted, did absolutely no validation on the server side. To make matters worse, I saw all three things on the same site, one that I did not write, but which I was hired to debug, repair, and complete. I’ve seen most of those things in plenty of other places too, at least the client side mistakes.
Another thing to keep in mind is that if your site will not work with javascript disabled, you are closing out a significant portion of your potential users. And I’m not just talking about the wierdos (I say that affectionately) who use Lynx for normal browsing. In the worst case, you’re locking Google, Yahoo, MSN, and the other search engines out of your site. (If that doesn’t matter to you, it probably should.)
Every site should be functional and usable (at least) without javascript. If it has more bells and whistles with javascript, fine. But it should still work without it.
A statistic I found recently stated that a significant number (I heard about 10%, but others dispute that, saying that it is 5% or less) of users have javascript completely or partially disabled in their webbrowsers. And no, that isn’t one of the 93.61% of statistics that get made up on the spot.
I hope this isn’t perceived as a rant, diatribe, or flame.I’m just trying to help people not to make the same mistake that so many people have already made (and in many cases, are still making).
As my final plea, please don’t depend on javascript for validation. Use it if you like, but back it up with all the same (or better) validation on the server side. It will make you much happier.
– Mac Newbold
It has been several years that I have been looing for an adequate solution to the task of giving a user non-shell, chrooted, secure server access. I finally found that in an small application called scponly. It was simple to install, easy to configure and use, and got the job done beautifully. A script is even provided for setting up accounts, assisting you in configuring all the options. I would recommend this to anyone looking for a similar solution.
A recent discussion in the UPHPU IRC channel (#uphpu on freenode.net) prompted me to submit something I use for validating email addresses. There’s only so much you can do without actually sending a message, but this code uses three steps to check the address.
First, it checks it with a regular expression, to verify that it uses valid characters for the various parts of the address, and there is an @ and at least one period, and they’re in the right places. Second, it turns to DNS to verify that the domain exists. (DNS calls will probably need tweaking to work on Windows servers.) Best case is that it has an MX record for the domain. Second best is to verify that the domain simply exists and has an address. If it can pass the regular expression test and the DNS test, then it is most likely a valid address. The things we can’t easily check are user-related, like user doesn’t exist, has exceeded quota, etc.
In places where I’ve done comparisons with and without this checking in place, I’ve found very significant reductions (probably around 80%) in the number of bounced messages. While this can be used just before sending, it’s often best to use it when accepting the email address from the user, to prevent bad addresses from getting into the system in the first place, and catch typographical errors. In cases where a long time has passed since the email was known to work, it may be helpful to check before sending the message as well.
function ValidateEmail($e,$v=-1)
{
global $verbose;
/* Return codes:
0: appears to be a valid email
1: didn't match pattern of a valid email
2: looks valid by the pattern, but no DNS records found
Try several things to make sure it is most likely valid:
1. preg_match it to make sure it looks valid
2a. If that passes, check for an MX entry for the domain
2b. If no MX, check for any DNS entry for the domain
*/
if ($v==-1)
{
$v=$verbose;
}
if (!preg_match("/^[a-z0-9.+-_]+@([a-z0-9-]+(.[a-z0-9-]+)+)$/i",
$e, $grab))
{
return 1;
}
# $grab[0] is the whole address
# $grab[1] is the domain
$domain = $grab[1];
$cmds = array("host -t MX $domain 2>&1 ","host $domain 2>&1 ");
foreach ($cmds as $cmd)
{
$dns = trim(`$cmd`);
if ($v)
{
print "n";
}
if (strpos($dns,"$domain mail is handled ")!==false ||
strpos($dns,"$domain has address ")!==false ||
strpos($dns,"$domain is an alias ")!==false)
{
# It is valid
return 0;
}
}
# If it didn't return yet, it's invalid, even
# though it passed the preg.
return 2;
}Questions, comments, and suggestions are welcome.
- Mac
administered by Anavi Design
colocated at Tier Four