Although I never wrote about jQuery here, I use it quite often and can pull of nice tricks with it. Also, bending any jQuery plugin to my will, was never a problem. But enough about me, you’re here cause of the book.

jQuery 1.3 with PHP is written by Kae Verens, a JavaScript and PHP developer. This book is aimed at PHP developers who have met only a few times with JavaScript and jQuery, but I believe even a novice programmer can gain knowledge from it – just be warned, the PHP examples are here for the sake of the examples only; about which the author warns throughout the book. As the author said: “This book is designed to help a PHP developer write some immediately-useful client-side applications without needing weeks of study”. And it will.

On the other hand, you need to know your HTML and CSS selectors, as the book only says that jQuery uses CSS selectors to select elements.

The examples in the book are well explained and commented!

The book starts off with an introductory chapter about jQuery, what it is, why the author chose it over other JS libraries, what projects use jQuery and so on…

The “Quick tricks” chapter shows some really quick but useful tricks, such as dynamic select boxes, contextual help or inline editing. OK, you may have all done this before, but it’s a good starting point for getting to know jQuery.

From chapter 3 to chapter 9, the author shows how to do things like validating forms, creating an event calendar, managing files and folders from the browser, rotating, cropping, resizing images (with ImageMagick!) also from the browser or making lists sortable by dragging and dropping items. Of course, no one wants to reinvent the wheel, so all the examples are using plugins – either from the jQuery UI collection or “standalone” plugins that are “too specific” to be in the said collection.

My personal favorite chapter is the “Data tables” chapter, which shows how to present and use table data on your website by adding sort, filter and pagination functionality to your table. The example shown uses a table with over 2 million rows, which is worth mentioning, cause this way we know that it’ll work on a large dataset also.

The final chapter is reserved for optimizing the front-end code and reveals some stuff behind jQuery and JavaScript in general (I personally never knew that there’s a speed difference between different type of selectors).

In conclusion, if you’re a PHP dev wanting to “spice up” your apps, this book will most likely worth the money spent.

You can take a look at the Table of Contents, read the sample chapter, or just buy the book!

We all know about Firebug, probably the best developer add-on out there, and how awesome it is and how many times it helped us debug some nasty Javascript code, mess around with CSS and HTML on-the-fly, to track the time load of every external page element our app loads… It’s so cool that it even has it’s own add-ons! (FirePHP, YSlow and FireCookie). Really, it helps our developer lives to suck a bit less.

Note: the following text is not about bashing other developers and their works, but to highlight the importance of proper input filtering. I myself have failed on this, several times.

Let’s go back to the part where we mess with the HTML by the means of this, may I say, application. You can add, hide, remove HTML elements, add, alter, remove, attributes from HTML elements… Adding, hiding, deleting - boring; altering - fun! I have this urge to try to break every form on every website I find. Not to do any harm, just to take a look how my fellow developer did his job and if I see anything that’s not right, I try to contact him to fix that, cause, y’know, I’m a nice person… Anyhow, I recently found some sites where all the textfields and textareas were filtered properly and no harm could be done - all my “hack” attempts were caught by their application. Nice. Oh, look, a select box! Right-click, inspect element, value=”xyz”, change that to value=”abc”, submit the form… and poof! A sexy SQL error. All that with the help of our li’l friend, Firebug. The elements where the user is required to provide some information “by hand” were processed correctly, but the select box was not.

OK, let’s take this one step further. On a site where the user can register an account and afterwards can edit his or hers profile. I register, go to the user panel, the usual stuff - change email, password, location, DoB (Date of Birth)… A quick inspection of the source - a hidden field “id” with a number in it. Hmm… Quickly, I register another account, note the “id” on that second account, go back to the first account, change the “id” of the first account to the “id” of the second account, change the DoB (just to see any actual information changing), click submit… “Your profile has been updated successfully.” Mine? Not really, the DoB is like it was in the first place… Go to the second account… Oh boy. I successfully changed the DoB of the second account, with my first account. Now, I haven’t seen their source code, but I can imagine what was going on. Something like this:

$id = (int)$_POST['id'];
$dob = $_POST['dob'];

$sql = "UPDATE users SET dob = '" . $dob . "' WHERE id = " . $id;

On the positive side, when I entered letters in that hidden field, I was told by the app that I haven’t filled all the fields correctly, which means they filtered even the hidden field, but skipped to check if that “id” is actually me.

OK, I know, the title is “Bad Firebug!” and the problems are actually about filtering user input, but I needed a catchy title to have your attention on Twitter :P

Even tho a field seems “unchangeable”, with a help of an awesome little app, it becomes changeable. And dangerous.

Filter input, escape output :)

P.S.: On the image above you can see my profile on a bulletin board, where I changed my year of birth from 1986 to 986 with Firebug. The years are in a select box; the lowest value is 1910. You can see my actual profile here.

On a forum, there was a question today, about adding language “support” to the routes using Zend Framework. The guy wanted routes like /en/foo/bar or /de/baz. I wrote there an example for that using Zend_Router_Routes_Chain, so just posting that example here, too :)

For what chains are for, is described in the manual, so I won’t be covering that :P

Basically, we’re prepending the language route to the other routes. This way, we have defined the route for the languages in one place only, plus, the other routes don’t have to worry about the language, too.

// this goes in the bootstrap class
public function _initRoutes()
{
    $this->bootstrap('FrontController');
    $this->_frontController = $this->getResource('FrontController');
    $router = $this->_frontController->getRouter();

    $langRoute = new Zend_Controller_Router_Route(
        ':lang/',
        array(
            'lang' => 'en'
        )
    );
    $contactRoute = new Zend_Controller_Router_Route_Static(
        'contact',
        array('controller'=>'index', 'action'=>'contact')
    );
    $defaultRoute = new Zend_Controller_Router_Route(
        ':controller/:action',
        array(
            'module'=>'default',
            'controller'=>'index',
            'action'=>'index'
        )
    );

    $contactRoute = $langRoute->chain($contactRoute);
    $defaultRoute = $langRoute->chain($defaultRoute);

    $router->addRoute('langRoute', $langRoute);
    $router->addRoute('defaultRoute', $defaultRoute);
    $router->addRoute('contactRoute', $contactRoute);
}

Assuming that we have an Index controller, with actions index and contact and a Foo controller with actions index and bar, paired with the routes from the above example, we could do requests like:

/ => /index/index/lang/en
/de => /index/index/lang/de
/sr/contact => /index/contact/lang/sr
/en/foo => /foo/index/lang/en
/fr/foo/bar => /foo/bar/lang/fr

Requesting a page like, e.g. /de/baz, would give us a 404 page, cause we don’t have a Baz controller.

HTH :)

Happy hacking!

A few days ago I finished reading Keith Pope’s book titled “Zend Framework 1.8 Web Application Development“, so, after letting it “rest” in my mind for a while, here are my thoughts on it…

First, I must point out the “language” of the book – I was expecting a text that’s hard to follow, that’s full of words and sentences requiring at least two dictionaries by my side to help me out (hey, English is not my first language!), but, it was quite an easy and, if I may add, an enjoyable read.

If you think, that you’re just gonna sit down, read the book and know all about Zend Framework, boy you’re wrong! Yes, the book explains a lot, but you’ll still need to follow the example codes along the way and play with them to get really familiar with ZF.

The book starts off with a basic application (yep, “Hello world!”), explains the bootstrapping, configuring, working with action controllers, views and handling errors… The second chapter continues with explaining the MVC architecture, the front controller, router, dispatcher… It even has a nice flowchart about the whole dispatch process, great stuff.

From chapter 3 to chapter 12, the author is taking you through a process of building a web application – from creating the basic directory structure, over the hardcore programming stuff to the optimizing/testing part. Chapter 4 gives a rather good explanation on the “Fat Model Skinny Controller” concept; chapter 8 deals with authentication and authorization; chapter 11 takes care of the optimization.

At last, my favourite part of the book is when the author has several “ways out of a problem”, he tells the good and the bad sides of each, picks out the best one and explains why did he choose that particular one. I hate it when an author just simply says: “This is the right way, trust me.”, without caring to explain why.

So, would I recommend this book to a friend who wants to start working with ZF? Absolutely.

Also, be sure to check out what Jani, Raphael, Rob and Sudheer have to say about this book (Jani’s and Rob’s reviews are not up yet, so I’m linking to their feeds!), too.

Happy reading! :)

Edit 2009., November 23rd: Added a link Sudheer’s post :)

O hai. First things first — someone should slap me for being such a lazy blogger. Somehow I lost all the motivation I had in the beginning, but looks like it’s back now :) I finally had the time to play around with the latest Zend Framework version (v 1.9 now). I managed to skip the whole 1.8.x version, so this whole Zend_Application stuff is quite new to me. I spent a few days poking around the manual and the code to make it work. And it works! Yey for me! And yey for Rob Allen for his post on Bootstrapping modules in ZF 1.8!

Zend_Tool is an awesome tool. Creating a new project is like “zf create project project_name” :) And the new bootstrapping process with the Bootstrap class is somehow much clearer to me now… Anyways, lets skip to the code.

The goal

I wanted to set up routes in such way that when a user requests a page, all requests for non-existing controllers/modules are directed to a specific controller (not the error controller). In other words, if we have controllers IndexController, FooController and PageController, anything but http://example.com/index and http://example.com/foo is directed to the PageController. This can be useful for CMSs or blogs to make pretty links. Here’s where the Zend_Controller_Router_Route_Regex stuff comes in:

$route = new Zend_Controller_Router_Route_Regex(
    '(?(?=^index$|^foo$)|([a-z0-9-_.]+))',
    array(
        'controller' => 'page',
        'action' => 'view',
        'slug' => null
    ),
    array(
        1 => 'slug',
    ),
    '%s'
    );

$router->addRoute('viewPage', $route);

Basically the regex does the following: if it’s index or foo don’t match anything, thus calling up those controllers, in any other case match what’s requested and pass it to the PageController’s viewAction as the slug parameter. The fourth parameter, the ‘%s’, is needed so that ZF can rebuild the route in components like the Zend_Navigation.

Now, when the PageController, viewAction get’s called up, we can check, for example, if a page with that slug exists (like, in a database). If it exists, show the content, otherwise call up a 404 page with the error controller. In this fancy and sexy way we can call up pages without passing ID’s or even letting the user know what part of the website is working on his request. He just request’s http://example.com/some_random_article and kaboom! he get’s the content :)

Page navigation

Oh the joy when I saw Zend_Navigation in the library! And it even includes view helpers to help us render links and menus and breadcrumbs! Yey! There are a several blog posts which go in details about Zend_Navigation, so I won’t be bothering with that. What I wanted to make with Zend_Navigation is to have a menu of all the pages rendered everywhere. Here’s where action helpers kick in. I made an action helper which makes up the structure of the links/pages. Something like this:

<?php
class Zend_Controller_Action_Helper_LinkStructure extends
        Zend_Controller_Action_Helper_Abstract{
function direct(){
$structure = array(
    array(
         'label'=>'Home page',
         'uri'=>'/'
    ),
    array(
         'label'=>'Articles',
         'uri'=>'',
         'pages'=>array(array(
                                  'label'=>'Article 1',
                                  'uri'=>'article_1'),
                              array(
                                  'label'=>'Article 2',
                                  'uri'=>'article_2'),
                         )
    )
);
return new Zend_Navigation($structure);
}
}

This is a simple example of the structure; I’m actually making it out from the database, with all the categories, subcategories and pages.

Links everywhere

To have this menu on all pages, we need to render it in the layout.phtml. Rendering is quite simple:

// somewhere in layout.phtml
<?php echo $this->navigation()->menu(); ?>

Of course, we need to pass the menu to the navigation helper somehow. To avoid doing $this->navigation($this->_helper->linkStructure()); in all the controllers, we could do that once in the bootstrap (any other ways to make it happen?):

// in Bootstrap.php somewhere in the Bootstrap class
function _initView(){

        $view = new Zend_View();
        $view->doctype('XHTML1_STRICT');
        $view->headMeta()->appendHttpEquiv('Content-Type', 'text/html; charset=UTF-8');

        // our helper is in app/controllers/helpers folder, but ZF doesn't know that, so tell him
        Zend_Controller_Action_HelperBroker::addPath(APPLICATION_PATH.'/controllers/helpers');
        // now get the helper
        $linkStructure = Zend_Controller_Action_HelperBroker::getStaticHelper('LinkStructure');
        // and assign it to the navigation helper
        $view->navigation($linkStructure->direct());

        $viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('ViewRenderer');
        $viewRenderer->setView($view);

        return $view;
}

There. Now we have our menu rendered on all pages. Sexy isn’t it? :)

That’s it for now. Hope someone will find this useful :) Now I gotta go, need to get ready for a punk rock concert tonight!

Happy hacking!