Why Do ‘Cool Kids’ Choose Ruby or PHP to Build Websites Instead of Java? — Here is a question that I have been pondering on and off for quite a while: Why do ‘cool kids’ choose Ruby or PHP to build websites instead of Java? I have to admit that I do not have an answer. Why do I even care? Because I am a Java developer. Like many Java developers, I get along with Java well. Not only the language itself, but the development environments (Eclipse for example), step-by-step debugging helper, wide availability of libraries and code snippets, and the readily accessible information on almost any technical question I may have on Java via Google. Last but not least, I go to JavaOne and see 10,000 people that talk and walk just like me.

Coach then goes on to basically not answer his own question, although he offers a couple ideas about the popularity of Ruby and Php in what some folks at Sun see as a Java world.

I don’t think there’s any surprise about why the Ruby and Php are so popular. Unlike Java, when you write in a scripting language, you get immediate gratification and feedback about your web app. Many industrial-strength Java web applications are complex enough to require build and deploy scripts, multiple deployment tiers, and really beefy workstations to run local developer instances. Very little of that’s required with Ruby or PHP. This translates into something viscerally satisfying to web developers. The ability to change something, and then immediately see that change in the working application. Don’t like the change? Do a little tap, tap, tap on the keyboard and then reload your browser. Boom. Now you have a new version of the page.

This dynamic of small, incremental changes leading to immediate application feedback IS available in Java, using JSP. The problem here is overhead. In most shared hosting environments running Linux, there is usually no stable Servlet/JSP engine set up. This means the developer - oft times what corporate types like me call “Junior Developers” - are required to install the servlet engine themselves. That, or use the web development tools that are already available.

Like PHP.

Adobe Flex goes open source by ZDNet’s Ryan Stewart — Adobe is announcing the open source release of the Flex SDK. Included are all of the libraries and tools that are offered for free as part of the SDK. It’s part of a continuing trend by Adobe to be more open and it’s going to give developers access to the guts of Flex. This should mean better code, better components, and lots of good things for Flex developers and the Flex community.

That’s good news for developers - and even better news for companies wanting to deploy RIA as part of their web offerings.

The new version supports:

• Passing your AWS key as a parameter
• Fits in a standard 160X600 Skyscraper
• Searching for Books, DVDs, Software, and Video Games

Go ahead, take it for a spin.

How To Deliver Composite Applications with Java, WS-BPEL & SOA Java is an outstanding language for building components, services, and many applications that are vendor and platform neutral. The vast adoption of Java technology by the industry in the past decade is a testament to the power of Java. Development of new applications, services, and components using Java is not going away, but many organizations have progressively moved to the next phase in maturing their IT Infrastructure. This phase is driven by many factors including how businesses operate today, having to constantly adjust to market trends, and that IT has moved from being a support organization to being the backbone of business and, hence, needs to keep pace with the organization. Continuous and faster alignment with changing business needs, time-to-market, and cost are the factors that determine success in this phase.

IBM and Yahoo! state:

IBM OmniFind Yahoo! Edition is a no-charge, entry-level enterprise search software solution that enables rapid deployment of intranet and file system search for both employees and customers. View Flash Overview

The value add for SMBs is that IBM OmniFind Yahoo! Edition is not only free and built upon proven open source technology, but that it’s backed by IBM and Yahoo, as well as a community of volunteers that can help you tailor your solution to your enterprise search needs. Look for Springboard to be deeply involved with this technology, as well as sample OmniFind scripts to be posted here.

The key elements that I want to cover are:

• Formatting the Service Request
• Parsing the Resulting XML response

Before we go too far, take a look at the finished application in the left navigator of this site. Scroll down until you see the Amazon Search widget in the left navigator, enter a Keyword like “Adobe Flex”, select “Books” and press the “Find It” button.

One pattern that we find ourselves using repeatedly is the Strategy Pattern. The Strategy Pattern is one of the original Gang of Four design patterns. The Strategy Pattern is grouped with other behavioral patterns because it’s best suited to solving problems that affect the behavior of your program.

You can define the Strategy Pattern like so:

Encapsulate various related algorithms in individual subclasses of a common superclass.*

You might wonder why this would offer a solution that affects the behavior of your programs. Here’s the beauty of this pattern - if you’ve ever found yourself writing lots of if-else if-else blocks, or if you’ve ever written loads of long switch or case statements, then you’re going to love this thing. I’m not saying you won’t have if-blocks, but you’ll find that your code will become much cleaner and more flexible if you start applying some Strategy. Read on for the example.

The Strategy Pattern example on the phppatterns.com site, described here, uses something pretty common in web application programming - form validation. That’s the example we’ll use - and extend here.

Web applications are often filled with HTML forms, and these forms can often have many fields. It’s pretty common to have the web application validate the data submitted in these fields on the server - and this is often in addition to client (or browser) based field validation. This is usually a response to the ability that users have to disable javascript within their browser, opening up the possibility to completely bypass client-based validation.

So - let’s consider a simple form for user registration. In this application, you only have three fields that you’re concerned with - the user name, the password, and a second password field that you’ll use to confirm the user typed their password correctly. Told you the form was simple. Now, let’s look at the requirements - which are anything but simple:

Let’s assume your customer’s requirements are to make all three fields required for new users. For existing users, only username is required - but if a user enters a password, then the confirmation password field will also be required. In all cases, user names and passwords must be between 6 and 20 characters, can only contain letters and numbers (no punctuation), are case sensitive, and of course, the password and confirmation passwords must match one another. Finally - user names must not already exist in your user database. That’s quite a bit of business logic for such a trivial form, but you’ll probably find that the business rules that are important to your clients often provide you with the most complex challenges.

So let’s assume you have already created the form, and the logic to write the data into the database, and you’re ready to apply these business requirements.

You might be tempted to start off thinking in terms of if-then or case statements. I won’t even bother with the sample code because I want you to stop thinking that way - so I won’t enable your addiction to long, buggy, complex if-else if blocks.

Instead, let’s look at how we can apply the Strategy Pattern. Remember, we defined the strategy pattern is about encapsulating related algorithms in subclasses of a common abstract class, and we clearly have several related algorthms. In the one case, we have an algorithm for validating the username field. In the other case, we have an algorithm for validating the password (and confirm password) field. We also have an algorithm for validating whether any arbitrary required field is present or not. So - by the Strategy pattern - three related algorithms would mean three related subclasses.

What do these related classes have in common? In all cases, they encapsulate logic to validate a form field. So, we’ll start with with an abstract FieldValidator class - and create a simple interface: we’ll just have a validate() method that gets called during object construction. The validate method will check the business rules for the current subclass, and add any errors it encounters to the errorMsg list. We’ll also add an isValid() mathod that checks the error list and returns true if there are no errors. If validation fails, the validation error(s) for the current field will get recorded in an array of error messages that we can display back to the user with a getError() method. Once we have defined the superclass, we’ll then create three subclasses - one for the username, one for the password, and one for any required field. The UML for the FieldValidator strategy is presented here in the figure to the left.

Now that we’ve got the various classes defined, lets write the code. While this bit is almost identical to the PHPPatterns.com example, we’ll get to the extension shortly.

<?php
/**
 *  FieldValidator 
 * 
 * "Abstract" superclass for form field validation
 * Example of the Strategy Pattern presented on 
 * phppatterns.net
 */
class FieldValidator {
    /**
    * Private
    * $errorMsg stores error messages if not valid
    */
    var $errors;
 
    //! A constructor.
    /**
    * Constucts a new FieldValidator object
    */
    function FieldValidator() {
        $this->errors=array();
        $this->validate();
    }
 
    //! A manipulator
    /**
    * @return void
    */
    function validate() {
        // Superclass method does nothing
    }
 
    //! A manipulator
    /**
    * Adds an error message to the array
    * @return void
    */
    function setError ($msg) {
        $this->errors[]=$msg;
    }
 
    //! An accessor
    /**
    * Returns true if string valid, false if not
    * @return boolean
    */
    function isValid () {
        if ( $this->errorMsg != null && sizeof($this->errorMsg ) > 0 ) {
            return false;
        } else {
            return true;
        }
    }
 
    /**
    * Pops the last error message off the array
    * @return string
    */
    function getError () {
        return array_pop($this->errorMsg);
    }
}
?> 

And now, the three subclasses

<?php
/**
 *  RequiredFieldValidator subclass of FieldValidator
 *  Validates a that a required field is present 
 */
class RequiredFieldValidator extends FieldValidator {
    /**
    * Private
    * $user the fieldName to validate
    */
    var $fieldName;
    
    /**
    * Private
    * $user the fieldName to validate
    */
    var $fieldValue;
 
    /**
    * Constucts a new Validator object
    * @param $fieldName the Name of the Field
    * @param  $fieldValue The Value of the Field
    */
    function RequiredFieldValidator ($fieldName, $fieldValue) {
        $this->fieldName=$fieldName;
        $this->fieldValue=$fieldValue;
        FieldValidator::FieldValidator();
    }
    /**
    * Validates the field is present
    * @return void
    */
    function validate() {
        if ( $this->fieldValue  == null || “”== $this->fieldValue ) 
        {
            $this->setError($this->fieldName . ‘ is a required field.’);
        }
    }
} 
/**
 *  UserNameValidator subclass of FieldValidator
 *  Validates a username
 */
class UserNameValidator extends FieldValidator {
    /**
    * Private
    * $user the username to validate
    */
    var $user;
    
    /**
    * Constucts a new ValidateUser object
    * @param $user the string to validate
    */
    function UserNameValidator ($user) {
        $this->user=$user;
        FieldValidator::FieldValidator();
    }
   
    /**
    * Validates a username
    * @return void
    */
    function validate() {
        // do we have OK characters?
        if (!preg_match(‘/^[a-zA-Z0-9]+$/’,$this->user )) {
            $this->setError(‘User Login is null or contains invalid characters’);
        }
        // do we meet minimum length requirement?
        if (strlen($this->user) < 6 ) {
            $this->setError(‘User Login mut be at least 6 characters’);
        }
        // do we meet the max length requirement?
        if (strlen($this->user) > 20 ) {
            $this->setError(‘User Login is too long’);
        }
        // does the current username already exist?
       	if ( $this->user != null && $this->alreadyExists( $this->user ) )
       	{
            $this->setError(‘The User Login, "’.  $this->user .‘" is already in use’);
       	}
    }
	// alreadyExists - return true if the user name is in the DB    
    function alreadyExists( $userName )
    {
      // we’ll leave it to you to determine how implement this method as an exercise.
    }
}
/**
 *  ValidatorPassword subclass of FieldValidator
 *  Validates a password
 */
class PasswordValidator extends FieldValidator {
    /**
    * Private
    * $pass the password to validate
    */
    var $pass;
    /**
    * Private
    * $conf to confirm the passwords match
    */
    var $conf;
 
    //! A constructor.
    /**
    * Constucts a new ValidatePassword object subclass or FieldValidator
    * @param $pass the string to validate
    * @param $conf to compare with $pass for confirmation
    */
    function PasswordValidator ($pass,$conf) {
        $this->pass=$pass;
        $this->conf=$conf;
        FieldValidator::FieldValidator();
    }
 
    //! A manipulator
    /**
    * Validates a password
    * @return void
    */
    function validate() {
        if ($this->pass!=$this->conf) {
            $this->setError(‘Passwords do not match’);
        }
        if (!preg_match(‘/^[a-zA-Z0-9_]+$/’,$this->pass )) {
            $this->setError(‘Password is null or contains invalid characters’);
        }
        if (strlen($this->pass) < 6 ) {
            $this->setError(‘Password must be at least 6 characters long’);
        }
        if (strlen($this->pass) > 20 ) {
            $this->setError(‘Password cannot be more than 20 characters’);
        }
        if (strlen($this->conf) < 6 ) {
            $this->setError(‘Confirmation Password must be at least 6 characters long’);
        }
        if (strlen($this->conf) > 20 ) {
            $this->setError(‘Confirmation Password cannot be more than 20 characters’);
        }
    }
}
?> 

This is roughly the point at which the example on the phppatterns.com ends. After introducing the Strategy Pattern, and then providing the field validator examples, you’re given a little bit of code that shows you how to call you new validator classes. What would have made this an even better example is the recognition that, in addition to the tasks of field validation, you could just as easily apply the Strategy pattern to the task of form validation.

Remember our business requirements? Our requirements in this example say that some of the fields are required for new users, but different fields are required for existing users. Once again, we have related algorithms, which, in this case, are the individual form level validation requirements. In our example, the related “forms” are the new user form and an existing user form. Regardless of whether you actually use different HTML forms for these, you can think of their validation requirements distinctly - and can represent them as concrete implementations of a common FormValidator superclass.

Our new FormValidator class allows you to register new FieldValidator instances to it using the addValidator() method, and provides the abiity to call the validate() method on each one through the isValid() call. Let’s see how this code plays out:

<?php
/*
 * FormValidator
 * 
 * Abstract class that performs field-level validation
 * for a given HTML form.
 *  
 */
class FormValidator
 {
 	var $errors;
 	var $validatorList;
 	
 	function FormValidator()
 	{
 		$this->validatorList = array();
 	} 
 	/**
 	 * validate
 	 * 
 	 * Main abstract method that needs to be implemented in 
 	 * each subclass
 	 */
 	function validate()
 	{
	   $returnVal = true;
	   // Perform validation
	   // against each validator in the list
	   // every one must return true for this method
	   // to return true
 	   foreach($this->getValidators() as $validator) 
    	   {
      	  	if (!$validator->isValid()) 
        	{
        	    $returnVal = false;
        	    while ($error=$validator->getError()) 
            	   {
                       $this->addError($error);
            	   }
        	}
    	   }
    	   return $returnVal;
 	}
 
	function getErrors()
 	{
 		return $this->errors; 
 	}
 
 	function addError($message)
 	{
 		$this->errors[] = $message;
 	
 	}
 
 	function addValidator(& $validatorObject)
 	{
 		$this->validatorList[] = $validatorObject;
 	}
 
        function getValidators()
        {
                return $this->validatorList;
        }
 }
 
?> 

And now, let’s examine the FormValidator subclasses - for the New and Existing user forms.

<?php
/*
 * NewUserFormValidator
 * Validates that the business rules for new user form submissions are followed
 */
 
 class NewUserFormValidator extends FormValidator
 {
 	function NewUserFormValidator()
 	{
 		parent::FormValidator();
 		$this->addValidator( new PasswordValidator($_REQUEST[‘passWord’],$_REQUEST[‘confirmPassword’]));
		$this->addValidator( new UserNameValidator($_REQUEST[‘userName’]));
 	 	$this->addValidator( new RequiredFieldValidator(“Password”, $_REQUEST[‘passWord’]));
 	 	$this->addValidator( new RequiredFieldValidator(“User Login”, $_REQUEST[‘userName’]));
 		
 	}
 }
/**
 * ExistingUserValidator - 
 * This is a formvalidator subclass that gets called when 
 * a user record is updated
 */
 class ExistingUserFormValidator extends FormValidator
 {
 
	function ExistingUserFormValidator()
 	{
		parent::FormValidator();
		
		$this->addValidator( new RequiredFieldValidator(“User Login”,$_REQUEST[‘userName’]));
 
		// only validate password and the confirmation password if either one is present
		if( $_REQUEST[‘passWord’] != “” || $_REQUEST[‘confirmPassword’] != “”)
 	 	{	
	 	 	$this->addValidator(new RequiredFieldValidator(“Password”, $_REQUEST[‘passWord’]));
 		 	$this->addValidator(new RequiredFieldValidator(“Confirmation Password”, $_REQUEST[‘confirmPassword’]));
 		 	$this->addValidator(new PasswordValidator($_REQUEST[‘passWord’],$_REQUEST[‘confirmPassword’]));
 	 	}
 	}
  }
?> 

Now that the various building blocks are in place, let’s see how we might tie this together in our page controller script. You’re probably using some kind of MVC pattern for your system, right? At the controller level - all we’re really concerned with is if we’re dealing with a new or existing user. For new users, we’ll utilize the NewUserFormValidator to do the validation - and if it’s an existing user, we use the ExistingUserFormValidator. Let’s say we have already implemented a method to decide which validator to use. Maybe the User BusinessObject could tell us based on the value of some inbound action parameter. Sure. That might look something like this:

 
. . .
 function saveUser()
 {
               // assume we’ve already populated a user object from the html post
               // see the blog entry about using introspection for an example of how to do this easily
 
               $theUser = $this->user; 
 
		// assume form validators are related to business objects
		// get the appropriate validator for inserts and updates
		// often these are the same, but not always - it depends on the 
		// business object 
                // here we’ll use "action" parameter - which may have been the 
                // value of the user form submit button or a hidden field to help figure out 
                // what form validator to use
 
		$validator = null;
		
		if ($this->action == “NEW”)
		{
			$validator = new NewUserFormValidator();
		}
		else
		{
			$validator = new ExistingUserFormValidator();
		}
 
                // in a real system, make sure $validator isn’t null here
 
		if ( $validator->validate() )
		{
			$user->save();
			header(“Location: “ . $successPage);
			return;
		}
		else
		{
                    // since there are errors, let’s get the error list from the validator
                    // and pass that to back to our web form so we can display them
 
		    $errors = $validator->errors;
                    include $editorPage;
		}
 }
. . . 

So that’s it. Looks like a lot of work for such a simple form, huh? I agree - except, that in real world applications, you rarely have just one form, you might have dozens or more - each with dozens of individual form fields. The beauty of this sort of application of the Strategy pattern is that for each new type of field validation task, you simply create a new FieldValidator subclass - and then register the new FieldValidator on the appropriate FormValidator where it’s needed. For example, what if we add email address to our user form? You could easily create an EmailFieldValidator - and then simply add a line to call the addValidator() method in the appriate FormValidator class to use it. What if the field validation rules change as a result of supporting different languages or countries? For example, say you have a need to validate postal codes in the US and Canada. You could simply create US and Canada PostalCodeFieldValidator classes that encapsulate the rules for valid postal formats in those countries. In addition, it would now be pretty easy to add any number of new forms that contain complex validation logic. Need to start writing Contacts or Leads or Invoice details in your web app? Simply create a new FormValidator for each one, and then you business logic will be neatly encapsulated and ready for use as well as extension.

* Note: I talk quite a bit here about abstract superclasses when I discuss the Strategy Pattern. There’s absolutely nothing wrong with using an interface instead. So, if you’re a PHP 5 or Java programmer, and your problem is better suited toward an interface, then by all means, use an interface. Since I’m writing this example in PHP 4 - there really isn’t even any “abstract” nature to these superclasses. Don’t let that put you off - the main point here is to code to a public interface provided by your superclass so you can enjoy the benefits in each concrete implementation.

Suppose you’re building a web-enabled content manager (who isn’t?). You want to provide a set of web forms that let your client enter and manage information that gets stored in a database. Further, let’s assume you want to manage several different types of objects that are relavent to your client’s busienss in the database - say, for example, Leads, Events, Stories, Links, Product Reviews, and Blog Entries (maybe you’ve got a demanding client).

In this example, we’re not going to worry about the web forms, nor are we going to worry about the database. I assume you know how to build web pages, and that you know how to read and write data with a database. Instead, we’re going to focus on the business objects that ferry data from the web form to the database, and from the database to the web form. One of the key tasks you’re going to find yourself performing again and again is populating these business objects with data, either from the web form, or from the results of a database lookup.

So, how can introspection help? First, let’s build our base class for our business objects. Let’s call this BusinessObject, and let’s give it the ability to populate itself from an arbitrary array.

class BusinessObject
{
    function populateFromArray($someArray)
    {
        $fieldList = get_class_vars($this);
	foreach ($fieldList as $key => $value)		
	{
	   $this->$key = $someArray[$key];
	}
    }
 
} 

There it is. The call to get_class_vars($this) returns a list of all the member variables of the current object. We then loop through the list and assign the value of each element ($someArray[$key]) to the matching member variable ($this->$key). So, at this point, any subclass of BusinessObject will inherit the ability to populate itself from a PHP associative array. But what good does that do?

The answer lies in the fact that many things of interest to PHP developers arrive as arrays. Let’s add a couple more methods to our base class to illustrate:

class BusinessObject
{
    function populateFromArray($someArray) 
    {
        $fieldList = get_class_vars($this);
	foreach ($fieldList as $key => $value)		
	{
	   $this->$key = $someArray[$key];
	}
    }
 
    function populateFromRequest()
    {
	$this->populateFromArray(  $_REQUEST );
    }
    function populateByPrimaryKey($id)
    {
	$tableName = get_class($this);
	$pkField = $this->getPrimaryKeyFieldName();
		
	// Assume the PKs are numeric
	$sql = “select * from $tableName where $pkField = $id”;
	$result = mysql_query($sql);
	$row = mysql_fetch_array($result);
	if (isset($row))
	{
           $this->populateFromArray( $row );
	}
    }
} 

Now we have an BusinessObject that provides all its subclasses with the ability to populate themselves from an HTTP request, as well as from a database when given the primary key. Some things to note here: for simplicity, we assume that we’ve essentially followed Fowler’s Active Record pattern. In a real system, you may want to put the database access calls into a finder object (as per Fowler’s Row Data Gateway pattern). This wouldn’t change the code much - your finder would call the BusinessObject.populateFromArray() method in your subclass with the row instead of having the subclass do it itself.

Also - note that the introspective call: $tableName = get_class($this) in the populateByPrimaryKey method implicitly assumes that the name of your database table is exactly the same as the name of your BusinessObject subclass - so records for the Article BusinessObject are stored in an Article table, etc.

Finally, we’ve also assumed that member variables in your BusinessObject classes have the same names as the database fields - as well as the html form elements that are going to be used to populate them. This may not be realistic for your system, but it does add a nice level of predictability to your code as you won’t have to guess what the field mapping from form to object to database will look like.

What are the caveats? First - you may notice that little call to getPrimaryKeyFieldName(). You have to specify a name for your primary key field. OK - that’s not so bad. What might be bad is if, while looping through $someArray in the populateByArray() method, you don’t want to overwrite some fields - even if they’re not in the array. In this implementation, you could erase your own primary key in your BusinessObject if it’s not present in the list of fields in a web request.

To solve these problems, you can make the following adjustments to BusinessObject:

class BusinessObject
{
 
    function populateFromArray($someArray) 
    {
        $fieldList = getFieldList(); 
	foreach ($fieldList as $key => $value)		
	{
	   $this->$key = $someArray[$key];
	}
    }
 
    function getPrimaryKeyFieldName()
    {
        return $this->primaryKeyFieldName;
    }
 
    function getFieldList()
    {
        $allFields = get_class_vars($this);
        $excludeFields = $this->excludeFields;	
        return array_merge(array_diff( $allFields, $excludeFields));
    }
 
 
…
 
} 

Now, what we’ve done is placed a requirement for you to define 2 things in your BusinessObject subclasses: a field containing the name of the primary key, and an array of fields to exclude from automatic population. This lets you get around the problems associated with erasing metadata or other private data that you might want to keep track of - or may want to populate or calculate in some other manner.

Of course, that begs the question: What are the tangible components to a statement of the vision of a software project?

I think it’s just three things:

1. Identify who the stakeholders are: Find out who’s paying for the project, and who has final authority for approving the work produced during the project’s life. The stakeholders are not only paying the bills, they are the people who have the most to gain or lose from the success or falure of the project.
2. Identify what the stakeholders percieve as the business needs for the project. This might be one or more busines problems that they face, or opportunities that they want to take advantage of. You should be ready to help them think about how to articulate their business needs, and there are a number of techniques you can use, including interviews and surveys, brainstorming, workshops, and even role playing.
3. Identify the features of the proposed system that would meet these needs. The notion of a feature at this point is not the same as a software requirement. Think of features as services that the system will provide - and in this context - these are services that the business stakeholders and the development team both think will meet the business needs we identified earlier.