This is my second article about the Python programming language. And what we are going to learn today is handling user input from the console.

Python makes getting user input from the console very easy. For this purpose we can use the input function, which has this structure:

1
input([prompt])

This function only takes the prompt as an argument, which would be the text that the user would see before the console goes into input mode.

To store input from a user into a variable you can simply assign the return value of the function to a variable like this:

1
userInput = input('Give me a value');

With that little information we can make a little program that will get a number from the user and print it’s square.

I have been wanting to learn python for some time, mostly because a lot of my favority open source projects use it and seek people with that expertise, so finally here I am taking my first steps with python.

There are two things that really catch my eye about python:

– Doesn’t use brackets to group statement

– Doesn’t use semicolons to end lines

These two semantic rules of python freak me out a little, maybe because I am so used to brackets and semicolons that I can’t imagine a programming language that doesn’t use them. But they claim this makes programming easier, so I hope they are right.

Configuring an e-mail server for local testing on ubuntu is a really fast an easy task. You just need to install and configure sendmail with these commands:

1
2
sudo apt-get install sendmail
sudo sendmailconfig

The first command gets and installs sendmail from ubuntu repositories. The second command will run a configuration script that will ask you some questions about your configuration.

After you do this you have to add a fully qualified domain name to your hosts file or your server will not work.

Your hosts file should have something like this:

1
127.0.0.1 yourdomain.dev

You can really write the domain name you want but it needs to be fully qualified, that means it should contain a top level domain, in my example dev.

Table Data Gateway and Row Data Gateway are two design patterns that are very closely related. The former specifies an object that acts as a gateway from our system to a table in a database. This means that it will give us the functionality necessary to execute all common operation to that table easily by providing methods to all the CRUD (Create, Read, Update, Delete) operations.

Row Data Gateway provides very similar functionality, but it lets you execute those operations in a single record of a table.

The Zend implementation

Zend Framework provides us with Zend_Db_Table as an implementation of the Table Data Gateway pattern and Zend_Db_Table_Row as an implementation of the Row Data Gateway pattern. The best way to use these implementations is by extending Zend_Db_Table_Abstract and Zend_Db_Table_Row_Abstract respectively.

When I first read something like “AJAX and Zend Framework” I thought it didn’t make any sense. If AJAX is an HTTP request made by JavaScript then Zend Framework shouldn’t care how the request arrived.

This is kind of true; except when we are using layouts in our views. When we use layouts we don’t just deliver the content of the current action, but also other components that are common among all pages. This is a problem when we want to make an AJAX request that returns a JSON because it would return other pieces of code that would make very difficult to parse the response.

We could create a layout that is specific for AJAX requests that only prints the content of the current action, and that would work correctly. But there is another option that helps us easily switch from different types of replies with little configuration.

Zend Layout

Zend_Layout is the Zend Framework implementation of the composite view design pattern. It allows us to display default content for specific parts of a page (Menu, header, etc), and be able to display specific content for the current action.

In this article we assume the use of Zend_Application, we can check Using Zend_Application for bootstraping if necessary.

To start using Zend_Layout you have to add a line to the application.ini specifying the path of your layouts folder and another line to create a view resource. It should look something like this:

Test Driven Development (TDD) is a software development process that consist in writing unit tests for functionality that is going to be needed and once the test fails writing the code to make it pass. This process is repeated for every new feature or bug.

The most used tool for running unit tests for PHP applications is PHPUnit and is the one we are going to use. We are not going to go through the process of installation in this article.

Organizing tests

We will start by creating a folder for our tests. We probably already have a tests folder in our application root. If we didn’t have it we would have to create it. Inside that folder we are going to create two folders called models and controllers.

Our main suite will allow us to run all our tests with only one command. To create this suite we will create a file TestsSuites.php in our tests folder. This file will allow us to run all our application tests.

Zend_Db_Table is an implementation of the Table Data Gateway design pattern provided by the Zend Framework. It provides a set of methods and attributes useful for interacting with a database table, but can also be extended to provide custom functionality for your application.

In the simplest case you will only want to use the functionality already provided by Zend_Db_Table:

1
2
3
4
5
6
7
8
9
// PDO_MYSQL can be replaced for any of the databases supported by Zend Framework
$db = Zend_Db::factory('PDO_MYSQL', $options);

// Set the db adapter that will be used by default by instances of Zend_Db_Table
Zend_Db_Table::setDefaultAdapter($db);

// Create an instance that will work against a table named 'users'
// This is case sensitive and must match exactly the name of the table
$usersTable = new Zend_Db_Table('users');

Zend_Application is a class that provides an easy to use bootstrapping facility for your application. It also takes care of setting up the PHP environment and introduces autoloading by default.

Zend_Application requires a config file to work, so the first thing we need to do is create it. We will create the configuration file application/configs/application.ini with this content:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[production]

; Error reporting
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0

; Paths
includePaths.library = APPLICATION_PATH "/../library"
bootstrap.path = APPLICATION_PATH "/Bootstrap.php"
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"

[development : production]

; Error reporting
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1

This class allows lazy loading of classes upon request. This will in place prevent you from having to manually include the files that you will need in your application.

To use the autoloader you have to first include the file and then create an instance of it. This will usually be done in your bootstrapping class.

1
2
require_once 'Zend/Loader/Autoloader.php';
$autoloader = Zend_Loader_Autoloader::getInstance();

Once your autoloader is ready you can use any class you need without having to manually include the file it belongs to. For example, if after calling autoloader you had this line of code:

1
$frontController = Zend_Controller_Front::getInstance();

Zend framework will replace underscores (_) with directory separators (/) and look for the file Zend/Controller/Front in your include path(get_include_path()), if the file is found it will be loaded, if it is not found an error will be issued.