If you're interested in Google Wave, QuickBase, Zend my webinar on Wednesday, November 18 might help you with your own development in these areas. I invite you to register to attend this live Zendcast!

If you choose to use their iframe approach, you're putting the burden of maintaining the Facebook look & feel entirely on your own shoulders. If Facebook decides to change their design (which they do pretty frequently), your application will be forced to play catch up. All this puts the developers at the mercy of the platform. At least with Microsoft, you could choose when to upgrade when you had the time and money to burn a hole in your wallet. Facebook unfortunately doesn't provide best practices for enterprise development. This is no surprise when one discovers that their testing model involves inflicting new changes to subsets of their user base rather than going through the trouble of creating a testable development environment.

In the longterm, I think this will hinder v2 versions of Facebook applications. If Facebook wants to see more powerful enterprise integration, they'll have to provide more than what's required to create a "grow your own bonzai" application.

In the words of Ralph Johnson:

Designing software is hard. That is what makes it so fun! People who are good at designing software enjoy solving hard problems, at bringing order to chaos, at overcoming difficulties. Things that used to be hard are now easy, but we have moved on to working on problems that would have been impossible 20 years ago. OO programming helps but does not eliminate the difficulty of design.

I always assumed that Christopher Alexander's A Pattern Language was some source of inspiration for these gentlemen and I was surprised to find out that it wasn't in fact the case.

The author, Peter Svennson, is probably one of the most qualified people in the world to be writing a book about Dojo, considering he's a contributor. The book takes plenty of time covering some of the more common Dijits and how best to apply them in an application. Like any framework, knowledge of certain core components helps when extending that knowledge across the rest of the library.

As someone who's worked extensively with JQuery and Prototype, I appreciated the authors recognition of other frameworks, while being able to diplomatically keep the discussion focused on Dojo without diminishing the work done on the other site of the Javascript framework fence.

Before being totally entrenched in the various Dojo libraries, Svennson takes a couple pages to explain closures and Javascript's prototype based object model. I found his explanation enlightening and a good starting point for a conversation on Dojo. Svennson also sold me on Dojo's class building framework.

What kept me flipping through the pages was Svennson's passion for the technology. The writing style is informal and conveys his personal interest in Dojo's architecture. However sometimes I felt this same passionate writing starts to read more like a sales pitch and less like a serious technical reference.

If you're the type of person that likes to work through a practical application of the technology, Learning Dojo is probably not the best book for the job. Instead of figuring out how to build a form with client-side validation that showcases all the Dojo bells and whistles (which I don't think one app could truly do), you're invited to create custom events, learn how to build class structures with pseudo-inheritance, look at localization and ways of theming your application. Since a lot of these features are design-releated, they tend to feel disjoint.

Only in the last chapter are we introduced to "real-world Dojo". While the examples are great, they feel almost tacked on. Regardless, the multi-charting project and the CRUD application cover a lot of components that were already discussed previously. It's also nice to see that Svennson mentions how to unit test using DOH. Learning Dojo is by no means a book for beginners: as the book progresses, there are large chunks of markup that are loosely explained in passing.

If you're already married to Dojo, planning a site in Dojo or inheriting something written in Dojo, this book could be a great reference for getting familiar with the technology quickly. If this sounds like you, grab a copy from Amazon.

UPDATE: enjoy reading Chapter 6 for free online!

This stuff reeks of code smell. enormous functions, multiple levels of nested conditional logic, mixing of concerns... the whole thing is a case study on how NOT to write code.

The comments are also quite interesting.

This got me thinking about what would probably have been the worst PHP code I've written. I went digging through an old shell account I have and found something from the first CMS I wrote (probably around 5+ years ago):

 
 if ($upload == "photo")
 
	{
 
	$realname = $HTTP_POST_FILES['userfile']['tmp_name'];
 
	if (is_uploaded_file($HTTP_POST_FILES['userfile']['tmp_name']))
	{
		$filename = $HTTP_POST_FILES['userfile']['tmp_name'];
 
		$realname = $HTTP_POST_FILES['userfile']['name'];
 
		@chmod("$userfile",0777);
		copy($HTTP_POST_FILES['userfile']['tmp_name'],ROOT."/gallery/$imagefolder/$path/".$realname);
 
		$size = getimagesize(ROOT."/gallery/$imagefolder/$path/$realname");
		$size2 = filesize(ROOT."/gallery/$imagefolder/$path/$realname");
 
	// thumbnail
 
	$name = ROOT."/gallery/$imagefolder/$path/$realname";	
 
	$data = GetImageSize($name);
	$im = @imagecreatefromjpeg($name); 
 
	$w = $data[0];
	$h= $data[1];
 
		if ($w > $h)
			{ 
 
			$nh = 125; // This is the MAX height of your thumbs
			$ratio = $nh/$h;
			$nw = $w*$ratio;
 
			}
		else
			{
 
			$nh = 125; // This is the MAX height of your thumbs
			$ratio = $nh/$h;
			$nw = $w*$ratio;
 
			}
 
	if ($truecolour == "TRUE")
	   {
	        $ni=imagecreatetruecolor($nw,$nh);
	   }
	else
	   {
		$ni=imagecreate($nw,$nh);
	   }
 
	ImageCopyResampled($ni,$im,0,0,0,0,$nw,$nh,$w,$h);
 
	ImageJPEG($ni,ROOT."/gallery/$imagefolder/$path/$thumbfolder/$realname",$thumbqual); 
 
	@chmod(ROOT."/gallery/$imagefolder/$path/$thumbfolder/$realname",0777);
 
	 PRINT "
<p style=\"text-align:center\">
 
	 New image has been uploaded
	 If you are not redirected to the add image page <a href=\"$PHP_SELF?path=$path\">click here</a>
 
 
        <META HTTP-EQUIV=\"Refresh\" CONTENT=\"1;URL=$PHP_SELF?path=$path\">";
 
	}
 
	else
 
	{
	 PRINT "
<div style=\"text-align:center\">
<h1>An Error Occurred</h1>
 
You must select a JPEG image from your harddrive, and it should be less than
	 your upload limit (normall 2MB)
	 If you are not redirected to the image page <a href=\"$PHP_SELF\">click here</a>
</div>
 
        <META HTTP-EQUIV=\"Refresh\" CONTENT=\"10;URL=$PHP_SELF\">";
 
	}
	}
 

What's the nastiest thing you can remember writing?

The last comment by Martin noted that Zend_Db still had some unresolved issues for over a year.

Matthew's response was that this was a community project and that priorities are dictated as such. Personally, this doesn't affect me because I'm hedging my bets on Doctrine as an ORM layer for PHP development.

I like Matthew's response because the Zend Framework's philosophy encourages the development of loosely coupled components wrapped up in a development philosophy that encourages open contributions, financial backing (thanks to Zend, IBM, Sun and others), Unit Testing and project transparency. Here's where things go a little wonky.

Partnership with the Dojo community

While I really enjoy the implementation of Zend_Form on the server side. It allows multiple configurations, supports validation and while the decorators are a bit obtuse, on a whole, the Zend_Form libraries thin out controllers and encapsulate the concern of data entry in a clean manner.

In this point release, however it seems like there's been a whole outgrowth of Zend_Dojo_* classes that cater to doing AJAX development with the Dojo stack. I'm not sold on Dojo as a client-side framework. Past experience with it has left me trying to sort out a large, over-specialized collection of patterns that almost do what I want but not quite. I also don't like the coupling that occurs between the data set, the client-side validation and the magic rendering of panels (like Accordian's and content panes).

An alternative architectural approach

I would rather write the events, the theme, the data and the validation separately and reduce duplication in each of those patterns rather than in the UI pattern as a whole. In short, I think they've abstracted the wrong part. The same example can be seen in ASP.NET form validators from two years ago.

With Prototype, I can rapidly mock out a site with the functional requirements and use Script.aculo.us to accent the presentation with animation. My functional specification isn't muddied with fancy visuals and it lets me focus on the event handling, validation and end states rather than the fancy effects.

By using Zend_Dojo, you won't be tempted to build a well-exposed Service Layer from Zend_Controller. The advantage here is that you lead development towards service-orientation. If you need to write a Flex front-end, or a whole new business-tier, you at least have the beginnings of a web service, whereas if your working with Zend_Dojo's declarative templating syntax, you're already coupling the events, validation and data into heavily abstracted UI patterns.

This approach doesn't lead development towards the production of a refined Service Layer, but to a specialized Dojo-friendly interface with markup-generation from Zend_Form classes into Dojo markup. I would rather see a Zend_Form Service API where developers can send / receive JSON messages to inherited Zend_Form and then have the Dojo community write an Adapter that would send / receive messages from Dojo widgets.

A year or two from now, I wouldn't be surprised if people will look at the same Zend bug tracker, asking where support for Dojo went after the Zend team jumps to the next cool Javascript framework on the block and we find ourselves with Zend_Form_SproutCore or some other dependency.

At the beginning of the book, Martin Fowler suggests that there's a fork at the beginning of every development road where each project either ends up attempting to use Transaction Scripts, a Table Module, or a Domain Model. He argues that as project complexity increases, the two former design methodologies start to break down, causing code duplication and unmanageable complexity.

Transaction Scripts

Organizes business logic by procedures where each procedure handles a single request from the presentation. –Martin Fowler

In PHP, a transaction script sounds like a simple function call. It could be something as simple as:

 
saveWishlist($currentWishlist);
 

saveWishlist() could easily grab $currentWishlist, which could be an object containing a wishlist and a user ID and run an INSERT statement against a MySQL database.

This ends up becoming a problem if wishlists start having alternate transactions with similar logic. For example, what if the wishlist belongs to a preferred customer, or someone of a particular region? What if the application grows and now includes wedding lists and birthday lists? Each one of these procedures would perform near identical operations against the database.

Table Module

A single instance that handles the business logic for all rows in a database table or view.–Martin Fowler

Lists are beginning to become an abstract concept in the application. At this point, a list could actually be an object that represents a table row in the database. A Table Module pattern would have a series of objects that would encapsulate rules for particular tables.

We can have a MarriageList object representing a marriage_list table, and a BirthdayList object representing a birthday_list table. In each of these objects, we would put business rules specific to each class / table.

A Domain Model

An object model of the domain that incorporates both behavior and data.–Martin Fowler

Now a one-table-per-list approach to an extent... until the marketing director calls up the CIO and says that it would be really cool if you could "share" lists with friends (since he read that O'Reilly article from two years ago about Web 2.0).

All of a sudden, lists become a complex construct in your application. They start looking more like this:

Each List object might have its own business rules based not only on what type of list it is, but also who is asking for it (is it your friend's birthday list that he's sharing with his girlfriend, or is it your own birthday list that you're sharing with your girlfriend?) The object graph above would allow some really neat code like:

 
$myFriends = $currentPerson->getFriends();
 
$myFriendLists = array();
foreach ($myFriends->getFriends() as $friend)
        $myFriendLists[] = $friend->getAllLists();
 

what we would end up with is a collection of all our friend's lists. We could do cross-referencing or reporting to see who likes what and create object graphs with entities or help users visualize common products among friends for each occasion. Note that these objects may or may not (and probably don't) correspond to rows in a database.

This kind of work is nearly impossible with a Table Module approach because modelling the person->friend (one-to-many) and correlating that with the person->lists (one-to-many) doesn't make much sense in the database directly, unless the whole application is based on list sharing. The code above could help form an Entity called FriendLists or we could make an Entity called FriendWeddingLists. Making these distinctions in code is much easier than in a normalized database.

Is a Domain Model Worth It?

I would say that in most cases, the answer to that question is no, however a lot of the tools in the Zend Framework and Doctrine facilitate the building of preliminary Domains. We can create simple object graphs and separate our models from the controller layer (anything inherited from Zend_Controller) through Repositories that aren't REAL Repositories by Evans / Fowler's definition. Regardless, they provide a coarse interface for the Controller to interact with the underlying data model.