October 25, 2005

The PHP Collaboration Project

Over the course of the last couple of weeks the PHP Collaboration Project has been unveiled. This effort is being supported by many big players in the industry (such as IBM, Oracle, MySQL and Intel among others). So what does this group aim to achieve through this collaboration?

The full description of goals indicate that initially two primary agendas will be pursued. The first is to team up with the Eclipse Foundation to create a new development IDE specifically optimized for PHP developers. While this isn't exactly a new idea, I must say that I would welcome such a standardized tool with the support and weight of most of the industry behind it. Dreamweaver is nice, but it's pricey and not really designed to address my object oriented programming needs like a full IDE could.

The second goal of the PHP Collaboration Project strikes me with less enthusiasm. It calls for the creation of a new framework called the Zend PHP Framework, described as follows:
A Web application framework which standardizes the way PHP applications are built. The Zend PHP Framework accelerates and improves the development and deployment of mission-critical PHP Web applications.
I was under the impression that this framework is already in place...and that it goes by the name PEAR. I guess I'm mistaken. The Zend PHP Framework documentation is rich with words like "simplicity", "clean" and "extensible". In my humble opinion whatever framework they devise will likely be a little clunky until someone gets around to adding namespace support (currently implemented in PAT). Namespaces would likely go a long way towards helping them achieve the organizational goals of this proposed framework.

Unfortunately, it doesn't appear as if Zend or their partners have released any code yet. Perhaps I'm a bit of a skeptic, but I find it difficult to ignore the coincidence that this collaboration was realized mere months after the EDC reported a significant decline in PHP's adoption and usage. You can almost hear Zend exclaim "Oh snap, PHP kind of sucks for larger enterprise sites and people are starting to notice! We'd better do something!"

Well, they've announced something. Hopefully they'll follow through and help usher in some standardized tools that will continue to make PHP a viable option for web applications.

October 15, 2005

Data Models

One of the many features that was celebrated by the introduction of .NET was the flexibility of the new ADO.NET data model. For the first time developers had an opportunity to address in-memory data in a standardized way thanks to the System.Data namespace. It allowed access to the data source of choice either via DataReaders (a similar concept graced classic ASP) or by using the new DataSet object. With DataSets developers no longer had to rely on hitting the database each and everytime they required a result set for their pages. Instead they could load the result set once as an in-memory representation of their data and then proceed to work with it as necessary.

While DataSets allow for a great amount of flexibility, they are not a perfect solution for every occasion. For instance, they're generally not a great option to use if you need to cycle through an incredibly large result set. Using a DataSet in this circumstance will likely strain the memory of your server. Additionally, DataSets are a tad bit slower than DataReaders. These are important considerations when planning your solution.

So what is PHP's equivalent of ADO.NET's rich data model? Well...there isn't such a thing. At least as of this writing there is no component within the standard PHP distribution that allows for this kind of behavior. PDO is on the way for PHP 5.1, but this only offers a standard API for addressing multiple databases - not anything in the way of an abstact in-memory representation of the targeted data.

For the most part I get the sense that the PHP community doesn't see this as a problem. There are other worthy priorities that are currently steering this open source project (for example, Unicode support in PHP 6). And even though PHP supports object-oriented features, its extensions are widely functional (SPL and MySQLi are among the small group of exceptions). With this in mind, PHP doesn't strike me as an environment where a heavy object like a DataSet is likely to flourish.

All the same there are times when something like a DataSet would come in handy in PHP. Say, for example you pull a small to medium-size result set from your database. The page that you are working on requires you to sort or transform this data and display it in several different ways. In ASP.NET this would be no problem. You could simply use a DataView object on your DataSet and be on your way. But how could this be addressed in PHP? You could query the database each and every time your page needs to order/organize this result set...but this is bound to slow down your application.

You could definitely write your own data model in PHP or search for an open source implementation - these are very viable options. Here's a cheap way to emulate partial functionality of the DataSet in PHP:
<?php
//Select resultset and save it's rows as elements in an array
$sql= "SELECT * FROM TABLE";
$result = mysql_query($sql, $db);
$resultarr = array();
$resultcount = 0;
while ($resultrow = mysql_fetch_array($result)) {
$resultarr[$resultcount] = $resultrow;
$resultcount++;
}

/*
Now throughout this page you can use PHP's array functions to transform the result set for each of the times the data has to be displayed differently
*/
?>

This approach is quick and dirty but it may allow you to reduce the queries on your page while you are preparing or searching the web for a more robust open source option.

October 11, 2005

Access Denied

In many web shops it's all too often the case that accessibility features get ignored. Either the schedule doesn't allow for the extra time involved in implementing and testing these features, or they just don't bubble up the chain of importance to become any sort of priority. For some unexplainable reason it can be easy for the development community to forget that there are millions of people in the United States alone who have disabilities that can affect the way they interact with software.

What strikes me as morbidly amusing is the notion that sites might generally become more accessible as a result of the recent SEO hype, rather than recognizing the value of accessibility in and of itself. For example, making sure alternate text is available and formatted properly for webcrawlers is also likely to benefit those who surf with screen readers. While many business owners might simply shrug and approve of this two-birds-with-one-stone mentality, it seems as if the ethical implications go silently unaddressed. Don't developers have a responsibility to try to make their software as inclusive as possible for all different kinds of people?

Watchfire has a good site that allows you to test pages for "quality, accessibility and privacy issues". In addition to summarizing other concerns, it gives a good run down on instances in your source where you are not meeting accessibility needs as defined by the W3C Web Accessibility Initiative and Section 508 standards. After playing around with this tool I was surprised to discover that even large portal sites have some accessibility problems that need to be fixed. It may be helpful and make you more aware of accessibility issues within your own sites to run this or a similar tool during testing.

October 08, 2005

Visual Studio 2005 Beta 2

For the past several months I've been evaluating the "Web Developer Express" flavor of Microsoft's Visual Studio 2005 Beta 2. So far, my experiences have been quite positive.

Although not unfamiliar with .NET, up until this point it just hasn't been much of a priority for me to consider this proprietary solution, especially given the outrageous price points on MS SQL Server, Windows Server 2003 and Visual Studio 2003. PHP does all I need for small to mid-sized projects, for the appealing price of free. To quote a famous muppet, "C is for cookie - is good enough for me." As you can imagine, I approached this new release with some hesitation, but was encouraged by the results.

First of all, Visual Studio 2005 loads up much faster compared to older versions. Additionally, old versions of Visual Studio required developers to have IIS installed on their local machines in order to be able to test their web applications. The 2005 version has thankfully done away with this requirement, so ASP.NET applications can now be tested directly from the IDE via an integrated test server. This time around they have also added an FTP utility to the Solution Explorer. Though unessential, it's a nice touch.

The 2.0 version of the Framework is filled with many more choices. To start with ASP.NET now has over fifty new controls! The Toolbox is packed with additional data model components, navigation tools, login controls, webparts and more. Some, such as the login controls, should really help speed up development of sites requiring authentication. Likewise, many of these new controls seem to be focused on saving time and making it easier for developers to achieve functionality that has required a good amount of coding in the past.

If you're anything like me, you probably feel most comfortable in the source view of your .aspx pages. Visual Studio 2005 now respects your style of coding. Changes in design view will not equate to massive reformatting in source view. Additionally, the HTML that is rendered by your work will now emit standards compliant XHTML. Finally!

The main item that disappointed me is the new ASP.NET Configuration Tool. It seems like a nice concept to be able to have one central area where you can manipulate application settings, security settings and provider models...but it just feels like a glorified web.config editor that was tacked on as an afterthought. I think this tool has potential, but it might take another release or two for it to fully mature.

However, when all is said and done, Visual Studio 2005 is shaping up to be a nice product. The "Express" family will be available for $49.00 and includes a stripped-down free version of MS SQL server. So much for using the cost barrier as an excuse to ignore .NET...

Feel free to dig in and evaluate it for yourself:
http://lab.msdn.microsoft.com/vs2005/