jQuery is not all that difficult to learn. The biggest thing you have to understand is all the different "selectors" that are available to you. Using selectors developers can query, in a CSS like way, for HTML elements, and then apply "commands" to them.

For example, the below JavaScript uses jQuery to find a <div> element within a page that has a CSS id of "rightSide", and shows it and "leftSide" and hides it.

As another example, the JavaScript below uses jQuery to find a specific <table> on the page with an id of "datagrid1", then retrieves every other <tr> row within the datagrid, and sets those <tr> elements to have a CSS class of "even" - which could be used to alternate the background color of each row:

This next example gets all links <a> in a specific <div> and attaches an onclick event to them:

Being able to traverse the DOM and locate HTML elements to attach events, behaviors, animations and CSS is priceless. But what about ASP.NET controls like the RadioButtonList, GridView, ListView, Repeater, and many others that we as developers like to bind to? How do we traverse them when they all get their ids auto-generated? That's what we will look at now! And with jQuery it's not that hard!

When you add an ASP.NET RadioButtonList control to a page, like below:

The browser renders the control to the code below:

As you can see, we don't have control over the generated items id tag. It would not be an easy task to guess what the auto-generated id tags are going to be. There's simply too many ways it can very depending on if you are using master-pages and or web-controls. The one thing that we do know is that somewhere in the id will be the id we gave to the control; in this case "rblCaseControl". Lucky for us this is all jQuery needs to go to town. Look at the code below:

This code uses jQuery to get all radio buttons that have "rblCaseControl" somewhere in their id tag. We could get the selected value of the radio button list using this code:

With this code we have now found the selected value from our ASP.NET RadioButtonList control using jQuery. Perhaps now we want to send that value to a web method in our codebind page using Ajax? Well we could use jQuery for that too! But, that's another article.

Further Reading:

• http://weblogs.asp.net/scottgu/archive/2008/09/28/jquery-and-microsoft.aspx
• http://weblogs.asp.net/mikebosch/archive/2008/02/15/asp-net-mvc-submitting-ajax-form-with-jquery.aspx
• http://www.chadmyers.com/Blog/archive/2007/12/13/using-jquery-with-asp.net-mvc.aspx

Let's start by looking at the code in its entirety; the people that just want to grab the code and use it can do so. I will then explain the code.

The Setup

Add the System.Net.Mail namespace. The System.Net.Mail namespace contains everything we need to send email using a Simple Mail Transfer Protocol (SMTP) server for delivery.

Modify the Web.config file to include the below:

The kicker and not well documented part to note is the from="admin@company.com" in the smtp tag. You can change the from address later, but the MailDefinition class needs this here.

That's it for setup. Now let's look at the first chunk of code.

Create The Plain Text Version

The MailMessage class represents an email message that can be sent using the SmtpClient class.

Pretty straight-forward. This just assigns the From, Subject and To properties to our mail message.

In this example they have the option of sending the email to more than one recipient. So we perform a check on the four optional text-boxes to see if they have email addresses and if they are not empty then we add them to our MailMessage instance. In addition, we append them to our StringBuilder instance which we will end up using later.

Here we simply create a string which we'll use as our plain-text email message. But remember, we only want to use the plain-text version of the email if their mail client does not support HTML. Therefore we use the AlternateView class and add it to our MailMessage instance. We could have chosen not to use the alternate view and just made it the body of our MailMessage instance, but not this time.

That's it for the plain-text version, now we will handle the HTML version.

Create The HTML Version

Notice we use the MailDefinition class this time and not the MailMessage class as we did with the plain-text version. That's because it's the MailDefinition class that allows us to to create an email from an HTML file. Notice the BodyFileName property that we have set to our "email.htm" file. This is just a regular old HTML file. Lastly, we set the IsBodyHtml property to true.

The above code adds two images to the HTML file. The EmbeddedMailObject represents an item to embed in a mail message. Notice the Name property. This is important because in our HTML file (email.htm) we have this <img src="cid:hdr" alt="" /> code which is where it maps to the image. This way of adding images to our MailDefinition object will send the images with the email. If you don't wish to send images with your email you may choose to simply add absolute paths to your images in your HTML file like normal. Just make sure the paths are absolute.

This is an important part. This is where we pass in fields to our HTML template. Within our HTML file we find this <%EVENTDATE%> . This is a placeholder that we use to pass in content. Pretty cool eh? Almost like a mail-merge in Word. So all the above gets mapped into our HTML template. Now we see the power of this solution. It sure beats creating a huge string. We have a regular old HTML file with the placeholders that we pass in the content. Any future changes can be done right in the HTML file. Nice...

Now the last code section:

The CreateMailMessage method creates the email message and does the merging of our replacement list with the placeholders. We also pass in the string that we created earlier. Remember the string held all the email recipient addresses. The last parameter is looking for a control that owns the MailDefinition. We don't have one so we just pass in a dummy control.

All that remains is to send the email message via the smtp protocol. If everything in your Web.config file is set up correctly your email should be on the way.

For example, let's say you have a div with an id of "contentTop" like below:

Because you have made the control a server-side control by adding the runat="server" attribute it will now be rendered with a different ID when it hits the browser (view the source code and you will see). It will get rendered as something like this:

This is because ASP.NET generates its own IDs to ensure that every element on the page has a unique ID. Developers that work with JavaScript and CSS will immediately see the problem. This causes difficulty when using JavaScript and CSS which rely on those IDs to reference elements, as they can't easily predict what the generated ID will be. When it comes to CSS specificity the ID selector is extremely useful. In addition, anyone that uses JavaScript knows that getElementById (or one of the JavaScript library ways) is the most popular way to target an element. So why the hell does ASP.NET do this to us? Honestly, I can't really tell why, other than the fact that they must not trust us enough to be able to uniquely ID our elements ourselves.

But I don't want to just complain here, I would like to provide some solutions too.

Solution

The solution will be found in the ClientID property of the server-side control. The ClientID property represents the ID that ASP.NET will use for the element on the client.

Using the ScriptManager we place the ClientID in a hidden form field. This can all be done in the code-behind file by using the following code:

Be sure to have included the ScriptManager to your page, like so:

Now we can use JavaScript to retrieve the value from our hidden form fields.

That's it, if you know of another way, please let us know.
Happy coding.

Automatic properties provide you with a shorthand for defining a new property. No more do we have to create the private property and then use Getters and Setters to access and set that property. Here's the old code:

Now here's the code using automatic properties:

Oh my! How nice is that? The C# compiler creates the Getters and Setters and the private fields for you automagically!

2. Initializers

We've talked about initializers before, but let's review anyway. You can use initializers to reduce the amount of work it takes to create a new instance of a class. Instead of this:

We can do this:

Short and sweet -- the way I like it.

3. Type Inference

This new feature takes a page out of JavaScript's book. When you take advantage of type inference, you allow the C# compiler to determine the type of variable at compile time. Here's an example of how you use type inference with C#:

Looks like JavaScript eh? Notice that we didn't declare a type? The C# compiler can infer the type of variable (it's a string) from the value you use to initialize the variable.

No performance impact results from using type inference. The compiler does all the work figuring out the data type at compile time.

Notice the use of the keyword var? You declare a variable of type var when you want the compiler to figure out the variable's data type all by itself.

Enjoy those three shorthand shortcuts and happy coding.

What is the difference between a struct and a class? When should you use a struct versus a class? How do you know?

What is the difference between a struct and a class?
It is simple, structs cannot be inherited from or extended. They can have properties, private variables, methods, and even constructors and deconstructors. Unfortunately, that is where they end in their likeness to classes. Classes on the other hand are extensible and can be inherited.

Finally, it should be mentioned that structs are stored on the stack as a by value type and classes are stored on the heap as a by reference type. What you do need to know is if you copy a struct to another variable, you will now have two copies of the entire struct in the stack, causing a performance hit (depending on the size). For a class, this is not true, the second variable gets stores the address to the original heap location, thus no performance hit.

So when should you use a struct versus a class?
Whenever you do not need extensibility or inheritance. As for the "How do you know?", you are the architect; during your analysis take into consideration what you might be able to re-use in the future.

The nice thing about classes are their advance functionality. You can extend upon them creating large webs of functional objects and you can use them as a refactoring foothold to make smaller chunks of reusable code (modularization). For example, let's say you have a class called "Person". This class contains information such as "First Name", "Last Name", "Middle Initial", "Birth Date", and "Gender".

Now let's say you want to extend that class to have "Customers" and "Employees". You would inherit the "Person" class and extend it with the additional information you want to store. Let's say the "Customers" class should have an "Account Number", "Credit Card Number", "Credit Card Expiration Date", and "Credit Card Type". The "Employees" class would have an "Employee ID", "Email Address", "Title", and "Department". Now if we didn't use inheritance, all of this extra data would all be in the "Person" class, and that would just look busy.

So here is the Employees and Customers classes:

Now that we have covered inheritance to show how to extend a class, let's tackle abstraction. Abstraction provides a mechanism to define methods that MUST be created by anything extending it. For example, let's say the "Person" class wanted to abstract the method to display the "Full Name". This way the "Customers" class must write it's own "Full Name" method and so must the "Employees" class.

Due to the abstraction, our "Person" class needs a few changes:

Now keep in mind that abstract classes can have non-abstract methods, however, you cannot create an instance of this class, it must be inherited.

Finally, interfaces solve the biggest problem with objects. In C# and PHP, you are only allowed to inherit from a single class, however, you can implement an infinite number of interfaces. Interfaces like abstract classes cannot be instantiated, they can only define the method definitions; they cannot actually implement the methods.

There you have it, in this article we learned how to use classes to extend, abstract, and interface your code to make smaller chunks re-usable and extensible.

History:
07/13/2007 11:44 AM
Added information denoting that structs are stored on the stack and classes are stored on the heap -- hat tip to Ramjee.

What language should I use to program my next project?

As someone who has been on a few of said forums, mailing lists, and chatrooms for a while now, I hate seeing this question. Yes, it comes around a lot, but repetitiveness isn't what bugs me about it. What bothers me is that there's usually very little background information attached to that question, which makes it as open-ended as asking what mode of transportation you should take to get to the store. I can tell you anything from a skateboard to a jet and either vehicle can get you to the store, but to give you the best answer I need to know how far you have to travel, what you plan on buying, and how much money you have, among other things. The same holds true for the programming language question, so let's look at some factors that can help you choose which language to use on your next project.

What do you want to build?

This should be the first question you ask yourself when choosing a language, because some languages are better at some things over others, and some language just plain can't work in certain contexts. Are you building a desktop application? If so, you might want to look at a language like C++ or Visual Basic over say, PHP. Conversely, for a web application, PHP or Ruby (optionally with a nice framework like Rails or Symfony) will get you up and running much faster than trying to write your own CGI handler in C.

Some languages, like C# or Java, try to do it all, so this question may not lead to one clear answer for you if those are among your options. Keep them in mind, and try to filter your selection down with the following questions.

What platform(s) am I going to be running on?

This is almost as big of a decision-maker as the kind of program you're writing. Some languages only work well on one platform, so if you're on another platform the choice gets limited pretty quickly. For example, if you're writing a Windows program you might not want to learn Objective-C and Cocoa, which is a programming framework for Mac applications. Conversely, if you're building a website that is intended to run on a Linux server, PHP is a much better option than C#. Many languages, like Python and Java, are cross-platform, so at first it may not look like it matters, but look closer. Some server-side languages might "work" on Windows, but with Apache and not IIS, or may not perform well on Windows relative to Linux/OS X. Yes, it might still be possible to work in a language on a second-class platform, but it might be more painful than it's worth.

What do I already know? Do I like it?

Prior experience is also a good way to gauge which language you should use. If you like a C-style syntax, the style of a language like Ruby or Visual Basic might make you scream and run back to the safety of curly braces and semicolons. On the other hand, if you've been writing Java code for the last 7 years and are TiredOfTheVerbosityOfItAll, then maybe a more terse language like Python would be a nice change of pace.

Does the language have features for my project?

Look at your project and see what your needs are. Is it a simple frontend to a database with a couple of forms? Well, just about any language is capable of handling something like that nowadays. Do you have to deal with processing large amounts of text? Well, Perl was built just for that so maybe it's worth a look. Different project requirements may make you decide to switch it up.

To conclude...

I'm not here to tell you which language you should choose. You and I may look at the same project and end up with two completely different ideas about which language is best to go with. I don't expect people to run through this process every time they come across a new project, but hopefully this article gives you something to think about when you decide you want to start playing with another programming language.

Often times when you belong to a forum you start stalking certain people. Every time the person you are stalking post and you notice it, you go read what they have to say because you know it's going to be good. Well, Louie was the first person I ever stalked

So when I was putting together the Search-This team I knew that I had to get him on board, it makes it easier to stalk him that way! We're glad to have you on the team Louie.

Enjoy Louie's bio below:

User Name: louissimps

• childhood ambition: marry a rich woman
• fondest memory: going to my grandpa's ranch
• favorite music: a little something from every genre
• retreat: the ocean
• proudest moment: the path I have lead so far
• biggest challenge: not going to college
• alarm clock: 6:50(snooze until 7:45)
• perfect day: coffee, surfing, lunch with my wife, afternoon nap, head to my favorite bar
• first job: busboy at a banquet hall
• indulgence: Belgian Ale
• favorite movie: too many to name, Super Troopers, Napolean Dynamite, Platoon
• inspiration: accomplishment

This time I am going to talk about the Database class, as every project now-a-days typically stores their information in a database. A good database class can save you time and memory in retrieving results. It should be able to cache previous queries, to recall them later, and it should clear out the results from memory when they are no longer needed.

As with previous articles, it should be stated that the below code will only work using PHP 5.

In this article, I am going to post my code first and then give a break down of the important segments. Again, this is my take on solving a problem for my applications and I am sure there are other approaches, but this is the one I am most pleased with.

That is the Database class I use in my primary applications, note that it currently only has support for MySQL and MySQLi, but it could be extended to use Postgres and ODBC easily. Considering you never know what applications or platforms you may be writing for, let this be the first lesson. Always, write your classes to work on any platform. If your first project targets only a single platform, that is fine, but make it so it can be extended to fit another platform without having to rewrite significant portions of your original code. Let's face it, if you had to rewrite significant portions, you would create a new file for each platform because you would not want to go back into previous projects and update the implementation of your classes.

Let's start out with the constant variable being used.

This is where the extensibility starts. Each different platform will be separated by a comma. Below the constants are the private variables for the class, and I will describe those as they are used. Now like the Error class, the Database class has an 'Initialize()' method too.

One difference between the Error class's 'Initialize()' method and the Database class's, is that the Database class requires parameters to be sent. This class needs to know a few things, which is why the parameters are required. It needs to know the type of platform being used, the server name/ip address, the port number, the database name, the username to connect, and the password for the username.

Notice, that I use the Database's 'Initialize()' method to initialize the Error class. Since I know all of my applications will be using a Database, this is a good approach for me, however, if you wish to use the Error class in applications that do not have a Database, then I strongly suggest taking the Error::Initialize() out of the above code and into a more global area.

Next, the Database Type needed to be validated. To do that, we call a private method named 'ValidDatabaseTypes' and pass it the type of database (or platform). In this case, it should be either 'mysql' or 'mysqli'.

This code is very basic, it simply looks to find the Database type passed to 'Initialize()' inside the constant string 'DB_TYPES'. If it finds the type, then it will return "true", otherwise, it will return "false". If it returns "false", it will then log an error, using the Error class, stating such.

After the database type the "Initialize" method then stores the information passed into the class variables. The last variable stores the connection reference using the "ConnectToDatabase".

The "ConnectToDatabase" method takes the type of database, which was stored in the "Initialize" method into the self::$type variable, and then runs the appropriate connection function in PHP returning the resource identifier to be stored back into the variable.

You may be wondering why I am returning the connection information, instead of just setting it in the "ConnectToDatabase" method. I prefer to have any private methods I write return back the information to my public methods so I am not second guessing where a variable got set. So it is strictly a readability reasoning and definitely a personal preference.

Back to the Database class, I finished off the "Initialize" method by running the "SelectTheDatabse" to select the Database to use.

Again, this takes the self::$type variable to define which function to run. Notice that the "mysqli" type is not listed in here. This is because with "mysqli" you have the ability to specify the database name in the mysqli_connect function.

Now that the "Initialize" method is out of the way and the private methods associated with it, we can start to focus on executing a query, fetching the results of an executed query, freeing the results of a query, and removing the cached results.

The "ExecuteQuery" which receives two parameters (the query, and a name/identifier for the query). The name/identifier will be used later for fetching the results. In short, it will also help cache the results to be retrieved later.

Before the query can be executed, it needs to ensure the connection to the database succeeded. Following that, there needs to be a name/identifier to store the query resource in. Each query resource will be stored in the self::$savedQueries array. This will save memory resources. Let's say you wrote a modular application and two modules need to run the same query. No matter which order they run in, when the first module runs the query, it will save the resource identifier of the query into self::$savedQueries and then the second module using the same identifier for the query execution will find that it was already executed and reuse the same query data. Thus, there was only one hit on the database for the query instead of two.

A similar approached was used in the "FetchResults" method too. Notice that only the identifier is passed to this method, as it will pull the query resource out of the self::$savedQueries and build a results array or it will pull the results from self::$savedResults and reuse what it retrieved earlier.

Just like the "ExecuteQuery" method, you can reuse any previous identifiers so long as they still exist in self::$savedResults. All of the information from each query will be stored in this variable until it is cleared out using "RemoveSavedResults" which will be discussed a bit later. Before we discuss that, I want to point out the necessity of the "FreeResults" method.

MySQL keeps results in memory until requested to free them. This is where the "FreeResults" method comes into play. It is a VERY good idea to clean out the memory space as soon as you can, hence why we are caching the results into an array to be reused. Note, that once you free the results, they will be unretrieveable using the Query Identifier returned by mysql_query and mysqli_query so the only way to reuse the previous information is to get it from "FetchResults". The "FetchResults" will grab it from self::$savedResults instead of self::$savedQueries.

Notice that it ensures the identifier exists in self::$savedQueries and if it does, it clears out the result information from MySQL and it removes itself from self::$savedQueries.

Now that takes care of the memory allocations by MySQL, but what if you are done with the results you fetched from MySQL and no longer want them cached for other pieces of your application? Well, I arranged a method for that purpose too. Enter "RemoveSavedResults".

This method is short and sweet. It checks that the identifier exists in self::$savedResults and then it removes the information stored under that identifier so it is no longer cached for the rest of the application's execution.

Wrapping it up...
There are a few other public methods in this class, but they are not very important to an application's design. They are there because I have found use for them within my own applications, and so you can keep them or remove them, it's up to you. Oh, and one of the MOST important pieces, the "DeInitialize" method. This should be executed at the end of your application's execution. This way, if you have multiple developers working on your project and one of them forgets to run "RemoveSavedResults" or "FreeResults", the "DeInitialize" method will ensure the information is cleared out and it ensures the Database connection is closed.

Well this concludes Part 3 of my series, and Part 4 will be focusing on a Design class. The idea behind a Design class, is to give your application a template based structure, so you can support multiple designs. Plus it will allow you to create a modular application, so you are programming pieces of the application rather than the whole. I realize that may sound confusing, but you will have to read my next part to get a firmer understanding.

Update: Sample of Use

With that said, I am going to outline the base classes that I referred to in the first article. To start out I will talk about the Error class, as if you do not have a good error handling setup, your application is doomed from the beginning.

It should also be stated that the below code will only work using PHP 5.

The Error class is probably the most important class you will ever write, as any error your application needs to throw should have a standard way of taking care of it. So the basic things you will need is a way to report the error, a way to view the error(s), and a way to determine if there is an error. Likewise, I designed the Error class to also accept Warnings. Items that are not errors but should be noted as a potential hazard or caution.

First I will start with the variables. Note that everything is marked "private static". This simply means, all of the variables can only be accessed within the class and that their values will be kept between all instances of the class.

Now let's discuss the variables.
$title = This is going to be an array for each Error's Title that is thrown.
$type = This is going to be either 'Error' or 'Warning' so it designates which was thrown.
$description = This will be an array for each Error's Description that is thrown.
$datetime = This is the error/warning date and time of when the error or warning was thrown.

These four arrays must keep in sync with each other, so every time an error/warning is logged, an element is added to each array.

$numErrors = Stores the number of errors currently logged.
$numWarnings = Stores the number of warnings currently logged.

Since the variables are now defined, lets work on the methods for the class. The first method is written to initialize all of the static variables. In layman's terms, it's to ensure all of the arrays start as empty and the counters start at zero.

To call your method you would use Error::Initialize();. Notice that there are no variables, just the class name followed by :: and the method name. This is due to the method being static and therefore you do not have to set a variable to interact with the class.

Like any good programmer, I also write a method to clear out the variables at the end of the execution.

Simply put, this ensures all of the variables are back to the values they started with in PHP. Hence why we wrote an "Initialize" method. Error::DeInitialize(); should ONLY be called when you are through with the errors/warnings generated by your application, otherwise, you will be wiping out all of the errors/warnings caught during execution.

Now you need ways of logging the Errors and Warnings, so those methods are as follows:

Just like the prior methods, calling these is no different other than you are to pass two parameters. For example, Error::LogError("Title", "Description");. Now the Error class is shaping up to take on its role, however, it needs a few more methods to put it into practice. As right now, what if we want to know if any errors/warnings have occurred? How about displaying all of the errors/warnings that have occurred? Finally, what if you only want to retrieve the last error thrown or what if you want to clear out the errors and warnings? Well, that is what the below does, and of course, feel free to extend it to your heart's content.

As stated at the beginning, your application will need a way to handle errors, and maybe even warnings. The above class, is one approach and the one I use in my applications. It definitely is not the only approach, so feel free to comment on error classes you have used in your applications.

See in PHP 4, everything was fairly easy to organize so long as you created functions for the tasks you did repeatedly, which is also known as "refactoring". You can say the same concept holds true in an OOP environment, but it is also different. It is different in the sense you have to classify the functionality enough to associate it with a class. One could argue you could still write a function, but I decided to go 100% OOP and stray away from functions just for the shear challenge, be it right or wrong.

The first challenge I found myself occupied with was the number of classes I would potentially need. For my projects I came up with a few obvious ones, such as, a Session class, Database class, Design class, and an Error class. The next challenge I had to think about was how to setup each class. Should they be made of static properties/functions/methods (take your pick), or should it be an object that requires being Instantiated (meaning, you have to create an instance of the object before you can call any of its properties/functions/methods)?

This posed a serious question regarding PHP and how it handles static objects. See at work we use .NET and primarily code in C#. .NET is considered to be extremely OOP, and that is primarily because of how you are to develop in it. Every page you make is a class, and all refactoring you do will be in another class. However, when you work with static objects in .NET only ONE of those objects exist on each server your application is running. This can become havoc in a multi-threaded environment. If your static method isn't fast enough, you may lock out another process because the prior one isn't finished yet. So it is no wonder I came to the question of whether or not this holds true to PHP.

The answer is 'Yes' and 'No', I think. See in .NET this issue holds true because the code is already compiled and the ASP.NET handler caches the compiled version and keeps the static object in memory until the Garbage Collector deems it unworthy and tosses it out. In PHP, the code is compiled when requested, so would this mean each thread has its own static methods? Why yes it would, so how can the answer be both 'Yes' and 'No'? Well, I answered 'Yes' as well as you have to take into account the other aspects of the server. Whose to say that PHP like .NET after compiling the static object decides to keep it in memory instead of destroying it with the non-static objects? No one. And I have yet to find any documentation that provides me with a solid answer one way or another. So, I answer the question as 'Yes' and 'No', but how did this help my decision process? It didn't.

My decision was still tough and I just decided I would take the approach of using both static and non-static objects. The Database, Design, and Error classes would be static, as I could careless if the object is shared across all threads (requests) or just each individual thread. Think of it this way, if it is shared across all threads then the Design will be caught in memory and load that much faster for User #2-#5 as the hard work was done by User #1. The Database connection is not going to change between each request either, so I lose nothing by that being shared either, and as for the Error class, this is for server errors, such as, failure to connect to the database or maybe an outside resource the application is using is not being responsive and will cause the application to not function properly. All of these can work in an environment where the information is shared across each request (like .NET) or if each request had its' own individual static object.

So why leave the Session class as non-static? The session class is supposed to be unique for each request. Each user will have his/her own Session object. It is a collection of information, such as, the User Account they used to login, or their Checkout Details if used for a Store. This information should NEVER be shared across requests. Hence, it is a instantiated object.

I have received several questions as to why I created a Session class to begin with, and it again goes back to wanting to write a fully OOP application based on my .NET experience. See PHP 5, PHP 4, and PHP 3 have this nice function called "serialize" and its' opposite "unserialize". This allows me to create an object of any type with however number of variables I want and turn it into a string representation. Likewise, after it has been serialized, you can return it back to the object type using the "unserialize" function.

A part of me has to attribute this to what I have learned at work, as that is where this initial idea came about. Why force the language to have to read the header three or four times to get three or four session variables individually, if you can request the entire set of data once and unserialize it back into an instantiated object? Speed wise, depending how much information you keep in session, you could be saving a lot of system resources. Likewise, you could be wasting a lot of your time as I speculate PHP does this for you. The $_SESSION variable is an array of information and I am certain it serializes that array into the browser header for you and unserializes it back out, so is there a reason to do it again? Probably not, but if PHP does not automatically do this, then the benefits are of great value to serialize an object and store it in a single $_SESSION variable.

After defining my base classes, I quickly noted that these could be used in any project, so it would be AWESOME if I could reuse them in every project I make, but not have to copy them. For this I do not have a solution yet. Partially because every application you deploy, or allow others to download, will need these files and thus it makes more sense to store them with each project. The point here, is if your project is for internal use only (meaning your own application and will not be distributed), then by all means, store the shareable files in a directory that your other projects can take advantage of. Therefore you do not have to create copies of your database connection class, or similar classes you may need. Since my project is distributed freely, I have to make copies of these files to use in this particular application.

In Conclusion...
So as you can see, designing an OOP application, be it in PHP or .NET, requires making important decisions right at the beginning. Determining the right time to use static methods vs non-static is crucial and there are right and wrong times for both. Likewise, keeping in mind the deployment process of your application will determine where you store your files that can be reused. If it is for internal only, then by all means, do not store them with a particular project, make them more accessible at a root level, however, if your application will be downloaded freely over the Internet, then your best choice is to store a copy of each file with each project you make.

Keep an eye out for my next writing as I will go into more detail on each of my four primary classes and how I made them so they would work with any project I design in the future.

Matt's passion has always been as a coder. Now that Matt has graduated college and become a full time software engineer there's not many languages he hasn't worked with.

Look for Matt's, or rather cpradio's first article this Monday titled: "OOP in PHP from a .NET OOP Perspective" - should be a good read.

I can't really welcome cpradio as a new member to the team, because he has always been part of the team. So just enjoy his bio below.

User Name: cpradio

• childhood ambition: to be a software developer, seriously, it was...
• fondest memory: looking at my old code and just realizing what an idiot I was back then
• favorite music: anything but elevator music, seriously, how do you not fall asleep to elevator music?
• retreat: hiking in the smokies
• proudest moment: three weeks of hammering an application, countless thankful users
• biggest challenge: writing quote engines for an insurance company and making it easy to maintain
• alarm clock: 6:30 AM on a good day, 4:30 AM on implementation day (project going to production)
• perfect day: my wife told me it was her wedding day, err... our wedding day.
• first job: PetsMart stocker/fork-lift driver
• indulgence: hard drives, I have 10 (in one PC) equaling 1.8 TB but that is not enough
• favorite movie: geez, I can't just pick one, that would be unfair to the rest of them
• inspiration: knowing knowledge has no limits other than a person's refusal to continue learning