debuggable

Sry folks, the tubes here in Argentina are pretty jammed sometimes. But Mark Story is live covering the whole event. Check it out and use it to convince your guiding powers for attending the next fest.

Will upload pictures and stuff here soon as well : ).

-- Felix Geisendörfer aka the_undefined

Hey folks,

this post is going to deal with the pretty common problem of paginating a search with the CakePHP framework.

The Problem

The problem is that a user inputs some search criteria into a form, the resultset exceeds 30 rows for example and the user must be able to browse through the resultset via different pages. The search criteria has to be the same everytime, the form prepopulated with the used search keywords/data and the resultset still has to match the input conditions everytime a new page is clicked.

This problem itself is in fact not much of a problem. We just need to store the form conditions somewhere and then hack it together. So what we are going to do is that we raise the difficulty bar a lot more by trying to get the pagination work over a HABTM relation.

Battlefield Briefing

We agreed we need to store the search criteria somewhere, so we can access it later. No we won't use the DB for that as it is overkill. We will also not use files, since many users may use the search at the same time screwing our hd. :P Yes, we will use the session for that as it is made exactly for these things.

For the example code we are going to use the "Advanced Search" of Flashfun247, a flashgame site which is one of my freetime projects. If you want to see some more of its code, feel free to ask.

We want to search for games based on some input conditions. The Game model is related to the GameCategory model over a HABTM relation, so the same game can be in many categories and a category contains many games. CakePHP's paginator cannot handle pagination over a HABTM so well in its current version. The incident here is that we want every game listed only once in the resultset - and not n times, where n is the number of categories it belongs to.

So we must at some point include a group by statement. However, the paginator will use that group by statement for its internal find('count') call as well, which it does to determine the size of the resultset. This will in fact corrupt the page count screwing us all over. We will see that we can trick the paginator, though. ; )

The View

To get us started, let's have a look at the view in /views/searches/advanced.ctp, which is very simple:

It should be pretty straightforward. The only weird thing here is that $formData array. It is basically the placeholder for our search criteria that the user originally typed into the search form field. The view only needs to know where the form data is and not where it comes from. We simply assign the data to the form helper so it can prepopulate the fields for us (line 7).

The user can input here a substring of the name/description/instructions of a game and he can pick a category where the game must be in. Notice the different order options as well as the string "All Categories" for the empty option of the select tag. One other remarkable thing is that we have both isset($games) and !empty($games) calls there. This is to differentiate if the user has submitted the form already ( isset($games) ) and, if he did, the resultset is not empty which allows us to display that "Nothing found" message.

Here is the /views/games/list.ctp view just so you have the complete code:

Straightforward... Let's move on to the paging element:

Notice the different checks at the start in order to figure out if we need to display a div at all.. This is called in the advanced.ctp view and the model GameCategoriesGame is supplied, which is a convenience HABTM model which belongsTo both Game and GameCategory.

The controller action

The controller action might appear a little big at first glance. However, every line has its purpose. This is in a SearchesController. You could have your own search() method though in about any controller.

So we are first loading all our game categories to populate the select tag. Then we check if there is a named parameter "page" given. If so, the user clicked on the Previous/Next/Numbered links. If it is not present, we might as well start at page 1. ; ]

Now comes the tricky part. We check if the form was submitted via empty($this->data). If it is submitted, we store all the form data in the session. If the form is not submitted we try to recover the form data from the session. If both the form is not submitted and there is no data in the session, but it still a Get request, something bad happened and we fire the user by asserting the yummyness of his cake.

The rest should be familiar - some processing of the $formData array to extract the proper conditions and order stuff. The most interesting stuff now is that call to $this->GameCategoriesGame->paginatorCount('game_categories_games', $conditions, array('Game'));. This enables us to paginate over the HABTM relation (Game HABTM GameCategory). Here is the code from the GameCategoriesGame model:

To make a long story short: You see we build up the count query on our on and then force Cake to use our calculated count via our own forcePaginateCount property of the model. The Group BY is already in there, we can supply extra conditions and have different queries for different types (see the switch statement in paginatorConditions).
Alas, we have to build the sql on our own for the JOINs, which can become a headache for more complex problems. Anyway, this code gives us enough flexibility to build the right pagination for every problem. :) If you can think of a problem this code cannot be used for, please let me know and we discuss.

The paginateCount() method could go into your AppModel, I just put it here to have the code in one place to keep it simpler.

Conclusion

The method presented has some advantages and disadvantages, as always. The advantages would definitely include that we don't have to extend the controller's paginate() method in our app controller. This is what many people do and what I did in the past as well. However, as always, it's not good manners to hack the core.
Another advantage is the flexibility of the code - with just one line, we can calculate pagination counts for almost every occasion, and even if we paginate over two or three HABTM relations (I can show you later).

Disadvantages include some bloat in your models and the need to write sql again (*sigh*), which can become very complex if you have to supply all the JOINS yourself for more complex problems. Apart from that the code does not yet have full integration of the containable behavior. However, that I can add later.

I hope you liked the article and can put it to some use. Credits go to mariano for the original idea for this. If you guys are interested in seeing how I coupled the "Save search" feature from here with all of this, feel free to ask and we can have some nice discussion.

Hey folks,

a bunch of bakers are starting to organize a regular CakePHP meetup in Munich. If you are interested check out their website. The first meeting is on Thursday 7:30pm!

Out of curiosity, anybody interested in having a meetup here in Berlin? Let me know and Tim and I will organize something after CakeFest.

-- Felix Geisendörfer aka the_undefined

Hey folks,

this is going to be my first blog post in German ever, which is borderline madness considering it is my mother language. Anyway, the book I'm talking about is written in German so it makes little to no sense to review it in English.

Das Buch Webentwicklung mit CakePHP ist ohne Übertreibung *die beste* Veröffentlichung, die es zur Zeit zum Thema CakePHP zu erwerben gibt. Ich hatte die Gelegenheit, in einige CakePHP Bücher (größtenteils Englisch) hineinzuschnuppern und es gibt derzeit wirklich nichts Vergleichbares auf dem Markt.

Doch zunächst einmal, an wen richtet sich das Buch? In Kapitel 2 gibt es eine Hilfestellung zur Installation eines lokalen Webservers. Kompletten PHP / LAMP Neulingen würde ich dennoch vom Kauf abraten. Ohne solide Grundkenntnisse in PHP und prinzipiellem OOP Verständnis wird man schnell untergehen. Wenn man diese Hürde allerdings genommen hat ist das Buch eine wahre Goldgrube. Eigentlich traurig, aber wahr: Auch Tim und ich als alte Cakehasen haben eine Menge Dinge über CakePHP gelernt die uns bis dato unbekannt waren.

Der Hauptunterschied des Buches gegenüber ähnlichen Büchern am Markt ist jedoch ein ganz anderer. Die Kommunikation der Philosophie. Kapitel 1 beschäftigt sich ausschließlich damit, zu erklären, was ein Framework überhaupt ist, warum man es verwenden sollte, was MVC ist etc. Klar, jedes Buch macht hier einen gewissen Versuch, die Grundidee zu vermitteln, aber Dirk & Robert gelingt es perfekt, die Motivation der Core-Entwickler zu verstehen und zu vermitteln. Dies ist unglaublich nützlich wenn es später darum geht, bestimmte Entscheidungen des Frameworks im Bezug auf Conventions, DRY (Don't repeat yourself), MVC, etc. zu verstehen.

Auch der restliche Aufbau des Buches ist gut durchdacht. Ein Blick in das Inhaltsverzeichnis verrät: Schon in Kapitel 3 wird mit der ersten Datenbankanbindung und der Scaffolding Funktion zur Sache gegangen. Anschließend folgen ganz klassisch Erklärungen zum Controller, Model, View, Helpers, Session handling, Components, etc.. Soweit so gut, das findet man auch noch anderswo erklärt.

Wo sich das Buch wirklich lohnt sind die schwierigeren Themen. Die Nummer 1 ist ohne Frage ACL. Es geht ja das böse Gerücht um, das lediglich Nate Abele (Entwickler der ACL Funktionalität in CakePHP) in der Lage ist, mit cake's ACL System zu arbeiten. Pustekuchen. Oder in den Worten der Autoren: "Wenn der Kuchen spricht, haben die Krümel zu schweigen". Das ACL Kapitel des Buches ist aus meiner Sicht für sich allein genommen den Kauf Wert. In ~20 Seiten wird einem ein exzellentes Verständnis der Architektur inkl. MPTT gegeben und an praktischen Beispielen erklärt, wie der Hase - pardon - Kuchen läuft.

Aber auch die anderen Kapitel müssen sich nicht verstecken. Das Buch erklärt auch i18n, AJAX, Unit testing, Plugins und Fehler Behandlung. Immer perfekt gelungen ist der Kompromiss der Informationsselektion. Klar, an vielen Stellen könnte man noch mehr Schreiben, aber die Autoren setzen sehr gute Prioritäten zwischen wichtigen und unwichtigen Informationen. Somit wird das Lesen an keiner Stelle langweilig und man kann rasche Fortschritte erzielen.

Um jetzt nicht des Lobbyismus für O'Reilly beschuldigt zu werden: Ja es gibt auch ein paar kleine Fehler die sich im Buch eingeschlichen haben. Davon ist allerdings lediglich einer frustrierend wenn es um die Sortierung von Model results geht, da wird an einer Stelle ein falscher parameter verwendet. Die restlichen Fehler haben eher kosmetische Dimensionen und tun dem Verständnis keinen Abbruch (zumal es sich wirklich um lediglich 3-4 handelt).

Nichts desto trotz: Wer des Deutschen mächtig ist und sich selbst oder einem Kollegen CakePHP näher bringen möchte sollte unbedingt zugreifen. Bei "Webentwicklung mit CakePHP" handelt es sich wirklich um ein außergewöhnliches Programmierbuch wo fast jedes Kapitel für sich den Kauf rechtfertigen kann.

-- Felix Geisendörfer aka the_undefined

PS: I have met Robert, one of the authors twice. He did however not even bother to bribe me with a beer so far (even when Tim and I visited him for Oktoberfest in Munich) so trust me if I say that I truly enjoyed reading this book and my endorsement for it comes from heart.

git ci -m "Updated sidebar" && git push && deploy blog && say "Done"

No, this is not pseudo code. I just ran this : ).

Also read the previous "use the terminal" post.

-- Felix Geisendörfer aka the_undefined