hqt homepage

25 08 2009

and a quick note, we released a new page about the distribution of supplies. its basicly just a company profile.
Its build with CakePHP and YAML CSS framework. Highlight is the Spamprotect by Capcha.


a quick note to „order“ your CakePHP Scaffolding add / edit Fields

26 03 2009

If you wonder why your edit and add function look so crappy by default, add in your css file a

div.input.text label, div.input.textarea label{
float: left;
width: 20%;

which just let the cake default view look a bit cleaner. This is no big thing, but i think everyone who uses cake will uses it. This is nothing special but its a common leak which most people forget caused of the small use of label (Using Label is extremly good for your code. It helps handicaped people to read your page and increase your usability (if you want to decorate the label for example) ).

And why a float object? Because „label“ is a inline html object. This means normal „width“ does not have any effect to it (until you let its float or change this by „display: block“).

a short view on Django compared to CakePHPphp

31 08 2008

I’m trying to get the difference between Pythons Django and CakePHP but iam more than depressed how many people (especially from the Django base) don’t like PHP at all (or make fun of it). I thought that there might be a good reason for it and compared the Frameworks against each other and mainly found out that most difference’s are just „small stuff“.

To compare this both Frameworks is quite easy. Both started nearly at the same time and try to reduce the „dont repeat yourself“ factor. Django and Cake both use a MVC (Model View Controller) like structure to reach this goal.
Both support Database Abstraction (Mainly both support the really important Databases -> Postgres and MySQL).

The Strength of Django is the smart Query generation. This is defiantly something CakePHP needs to work on. Testenviorments / Ajax / buildincompontents are the strength of CakePHP. Django should get rid of real html tags and replace them with functions. The Code looks cleaner in PHP to me (cause i like to have all information at one place), but i think bad formation of the code can annoy a lot of people which have to program with someones else code. The use of forming ARRAY’s is essential if you want to use clean CakePHP code.
Lets Talk about something damn important for Programmers -> Documentation. The good point on Django, is they have already a book out (even if they dont have a final release yet, but there will be a stable version soon. Only some days to go). Cakes documentation is really good, they just rewrote it and some parts are still missing. But you will find everything quite fast if you just get the main structure of the documentation. Djangos documentation is a bit under this but still really good to use. Cake has got a strong focus on the community behind it. With „the bakery“ and „CakeForge“ they give the users a easy access to all source people just produce. Thats something Django needs to work on.

Project Language Ajax MVC framework Push/Pull i18n & l10n? ORM Testing framework(s) DB migration framework(s) Security Framework(s) Template Framework(s) Caching Framework(s) Form Validation Framework(s)
CakePHP PHP Yes, Prototype, script.aculo.us Yes, Active record pattern Push Yes, Development branch Yes, Active record pattern Yes, Unit Tests Yes Yes, ACL-based Yes Yes, Development branch Yes
Django Python Yes Yes Push Yes Yes, Django ORM, SQLAlchemy Yes No (plugin exists, might be merged into trunk when more stable and feature complete) Yes, ACL-based Yes Yes Yes

One Reason why the Cake looks a bit cleaner to me is for sure the View Design. Its a bit more straight forward. Django does this on a more old fashion view. This makes it easier to new persons, but if you really want to separate the view to „designers“ it is cleaner to use Cake.

django view Cake view

{% if form.errors %}
Your username and password didn't match. Please try again.
{% endif %}
{{ form.username.label_tag }}: {{ form.username }}
{{ form.password.label_tag }}:{{ form.password }}

echo $form->create('User', array('action' => 'login'));
echo $form->input('username');
echo $form->input('password');
echo $form->end('Login');

Most important stuff can be found in CakePHP directly. Some important things need to be loaded for Django (like mptt) but therefor django got a „instant server function“ which can be loaded for CakePHP in additional (cakephp-instaweb). So both Frameworks have got software which need to be loaded if you want to use it for the most common needs.

Final Words:
CakePHP and Django are both good Frameworks. I think its mainly a question of what your settings for the final Product are. If you need to work with a normal provider (no vhost or something) django is out of that business. mod_python is only rarely spread yet, and to start a real server process is most of the time not possible.
If you don’t want to change a lot djangos generic views and Cakes scaffoldering both are great, but i don’t like totally preconfigured templates at all so i dont really care about them.

If you need the performance and got enough time and admin rights Django is the correct choice.
If you need to code faster, and dont want to do everthing on your own, CakePHP is the right choice.

Overall, there is only one bad choice -> to ignore a good framework at all. As long as you use a good framework you will produce code with a much better structure while you save hours. The Stepback to a non Framework based development is the only wrong decision. And after all, both are just copies of „Ruby on Rails“.


after testing a bit more with django and postgres i found some „leaks“ in definition. If you use PostGresql with Django the default table defintions (auth etc) wount generate correct OIDS for PostGres. In fact postgres dont need them, but only if you are sure that there are never 2 entries with the same value. For MySQL users this is no problem, cause with mysql you can delete the entry by using LIMIT 1 for the DELETE command. Postgres needs a sessified OID to do so. So if someone explicit does crappy things with the database -> the default Django design would be wrong and have to be altered.

And just cause many think its a feature that they have to use instat of apache webserver -> Django explicity tells you to not use the internal webserver for a productiv enviroment. Thats what they tell use about it:

Now’s a good time to note: DON’T use this server in anything resembling a production environment. It’s intended only for use while developing. (We’re in the business of making Web frameworks, not Web servers.)

And some Statistics from google where red is CakePHP (keyword : „cakephp“) and Blue is Django (keyword: „Django python“ otherwise the musicartist will be counted eiter)

just to come clear about this image: it should not display A is better than B, but it should give a view on popularity (one big fact is that PHP is more public than python, which is not the best descission). But the Graph can be a indicator for available addons / support by irc and all other community related issues.

Django is more or less deprecated. The projected has bean moved into other projects…

CakePHP mit Access Listen beschleunigen

13 03 2008

Ich habe mich heute wieder ein stück mit CakePHP beschäftig, da ich dieses für ein Projekt benötige.

Da ich gleich alles richtig machen wollte, habe ich mir das ACL Modul von Cake vorgenommen um meine anwendung gleich tauglich für Benutzergruppen zu machen. Dabei ist mir aber etwas unschönes aufgefallen. Cake fragt die Informationen immer wieder ab, wenn man diese nicht zwischenspeichert. Das kostet einfach massive viele SQL Queries die unnötig sind (ausser man braucht wirklich eine anwendung, wo sich alle paar minuten die Benutzerrechte ändern). Aus diesem Grund habe ich ein kleine erweiterung für den AppController geschrieben, die sicherlich für viele nützlich sein könnte.

Damit werden einfach alle Variablen in der Session zwischengespeichert. Sinnvoll wäre noch eine Erweiterung um einen statisch Klassenvariable, damit die werte nicht immer wieder (bei Nutzung mehrerer Classen die Instanzen vom AppController sind) mit dem Session wert Überschrieben werden. Spart wieder ein paar Prozessortzyklen.

Diese Funktion speichert die Access Controll Objects (ACO) in Variablen für den View, wobei jeweils ein „m_“ + Aco Name genutzt wird.

function defineRights(){
$todo = array('orders', 'uploads', 'packages', 'artnotranslates', 'articelgroups');

if($this->Session->check('User') && (true != $this->Session->read('Rights'))){

foreach($todo AS $task)


$this->Session->write('Rights', true);


$this->set('user', $this->Session->read('User'));

foreach($todo as $task)

$this->set('m_'.$task, $this->Session->read($task));


Diese Funktion schreibt alle möglichkeiten von Cake ACL’s in ein Hash. Man kann dann mit $m_ACONAME[‚read‘] z.B. das Leserecht im „view“ erfragen.

function writeToSession($rule = null){
if($rule != null){


$dummy = array(

'any' =>        $this->checkBAccess($rule),

'read' =>       $this->checkBAccess($rule, 'read'),

'create'=>      $this->checkBAccess($rule, 'create'),

'update'=>      $this->checkBAccess($rule, 'update'),

'delete'=>      $this->checkBAccess($rule, 'delete')


$this->Session->write($rule, $dummy);



Grundlage dafür ist die check Funktion von Cake. Theoretisch könnte man diese Methode auch verkürzen indem man den Rückgabewert von check direkt als return wert nimmt.

function checkBAccess($aco, $action='*'){
$user = $this->Session->read('User');

$access= $this->Acl->check($user['username'] , $aco, $action);

if($access === false)

return false;


return true;


So wäre auch wieder etwas mehr Sicherheit und Flexibilität für den Entsprechenden Designer der sich mit dem Design beschäftigen darf. Man sollte aber erwähnen, dass trotzdem eine Überprüfung im Controller für sichere Programmierung unerlässlich ist. Alternativ wäre ein zusammenspiel aus diesen Funktionen und $this->action möglich, jedoch wäre dann eine vollständige Auflistung aller Funktionen und nötig.

Die Funktion lasst ihr am besten per var $beforeFilter = array(‚defineRights‘); aufrunfen.