Recently in PHP Category

Well now as we have stored our images within the filesystem of the web server and the information in the MySQL database (see part 1 of this series), it is about accessing the files and the information.

Basically the needed steps are quite easy:

1. Prepare SQL statements in your model for data
2. Create Controller and View Template
3. Create a View Helper Plugin to grab the image.

I will not explain in detail how to build the SQL statements respectively the functions in the model and how to set up the Controller and View Template. You will find other posts on this blog about this topic and with links to good tutorials

The task is simple: Let the user (or someone else) upload an image to your server and store it in a predefined location. Additionally you would like to store some information, e.g. an user name, an image title and a comment in a MySQL-Db. As an experienced programmer you will maybe take the Zend Framework.
To handle just a few images, this is no big thing. Make a Zend_Form and enable it to upload a file and store the information according to your model in the database. That is it.

Well thinking a little bit further you may think about the names of your files and what happens when there are two files (one on the server and one to be uploaded) with the same name. You have a conflict. To be more precise: without any intervention the newer file (the one to be uploaded) overwrites the existing file. You have to explain the user where the old image has gone and why there is another image twice in your database.

You have two solutions to this problem:
# Scan your directory upon validation if there already exists a file with this name (or maybe you have stored the filename in the database and query the database) and decide what to do: rename file or do not permit upload, e.g. return a false on validation.
# You can use own filenames based on a MySQL auto-increment value, e.g. the ID-Column which holds the additional information (user name, title, comment).

I will show you how to implement the latter solution. In a second tutorial I will show you how to access this files.

As soon as you have a nice front end of your website, which should be functional (and compliant with current regulations), you will have to provide a contact form or a email-address somewhere. I have decided to show only my email-address, but wanted to protect it at least with a minimal encryption from mail-harvesters.

In an earlier version of my page I have used the template engine Smarty, which has some functions to encrypt your email-address with JavaScript. And I have to say that this worked fine for me so far. So my current page uses Zend Framework and I am not the great JavaScript-Coder. This is why I decided to try to merge this two codes together. And it works. Here comes how.

First you need to download Smarty.
You need a running Zend Framework Site.
And an editor.

Everyone who is using a relational database and has a good concept, meaning a loose coupling and a low redundancy of the data, needs from time to time complex/multipart queries in (My)SQL.
Zend Framework is supporting relationships within the Zend_Db class, which are quite nice implemented. But there is one big restriction: You need a concrete row to access the dependent rows declared in the model. For larger queries, e.g. for an overview or a list containing multiple rows, the relationships can be built with different solutions. All in all, I have found three different ways of establishing the relationship for one concrete row:

1. Build a View Helper (or a function) an run it on every row.
2. Use the Join-Command within Zend_Db_Table respectively Zend_Db_Select.
3. Run complex queries constructed in SQL-Language over Zend_Db.

Previous to an example of the last method, I want to discuss some Pros and Cons of the presented solutions.

View Helpers
The View Helpers are a nice solution. The function can be designed for re-usability and the Helper itself can be registered with the bootstrap for the usage within of all modules.

The clear disadvantage of this solution are the many queries needed for the multiple entries. Theoretically do you need for every entry one query. Which is not a big problem as long as you do not have a lot of queries at the same time. But if the application grows and your server gets some traffic you will get problems.

Join-Command
The Join-Command is a stronger method, since you need only one query to find the results for all rows. This reduces the load on your server and makes it easier to handle the request, since you have only one variable to deal with. Additionally this methods allows you to stay within the methods of the framework and thus having a consistent solution.

But there are some technical difficulties and problems with this method. You can only use it, if you want to use exactly 2 different tables. More than two are not allowed or at least have not worked for me (Version 1.7.2) and the query returned an error message, that the requested columns could not be found.

SQL-Statements
This method offers you the biggest flexibility, because you have no restraints from the framework and can work as usual known.

But you need some knowhow and may be not consistent with the framework. Additionally the queries can become very large and thus make your system slow as well.

I have already written here about the Dojo Editor. Generally this is a nice and clean Rich Text Editor (RTE), but with some deficits in the standard configuration. Two examples to this point: First the inserting of URLs respectively links is not enabled by default and second the inserting of images is not enabled either.

But this two options can be enabled quite easy. You can see a nice example of a quite good configured editor on this page here. The corresponding article for the how to is found on the page of rubicorp.com

There have been other articles around about the usage of the Dojo editor element in Zend Framework. The solution by Weier O'Phinney has been to write a view helper and use the editor in this way.

I have also started to use the Dojo components for my application and have been wondering how to access the editor, since I wanted an editor for my article bodies. So I looked a little bit around but found only the solutions which required to write own Javascript-functions and needed additionally hidden textareas to store the content respectively to access the content.

The previous article on this blog was about the dynamical select list with the Zend Framework and some introductory material (mainly tutorials).

Two weeks later I am still working with the Zend Framework and now the tasks getting a little bit advanced. So I had again to crawl the web a little bit to find a solution for my problem. The problem was to look up related values from a fetched row and display the complete results.

Normally I have done this in PHP with a Join in the Where condition(s) and could then, since I most of the time look that my column names are unique, access the values directly via the mysqli-object. You could also do the Join statements with the standard Select object in the Zend Framework, but I was not sure how then the result array should be accessed or if it would work the same way as in standard PHP. So I had to have a look into the documentation. But I have to warn you, the introductory example is so scattered in the whole documentation that you need quite a little time to have the complete example together. So I had another look into Zend Framework in Action from Rob Allen and Nick Lo (2007), where the example was nicely illustrated with an ERM.

As soon as I had gathered all informations and get the principle of how the relationship is represented in the framework, I could implement my solution into my existing application.