Ice-Tec.net

Dieser Artikel schreibt sich meiner Meinung nach fast wie ein Programm mit Symfony, man hat eine Idee und den Rest macht das Framework Statt stundenlang das Netz nach guten Cheatsheets zu durchsuchen oder selbst welche zu entwerfen, reicht ein Blick ins Symfony-Wiki:

• Symfony Development Cheatsheets

Weitere tolle Cheatsheets für die Webentwicklung findet man dann noch bei Added Bytes:

• RegEx Cheatsheet
• PHP Cheatsheet
• CSS Cheatsheet
• HTML Cheatsheet

Und zum Schluss noch für AJAX:

• JQuery Cheatsheet von Colorcharge
• Prototype

Im Gunde nichts weltbewegend Neues, aber hilfreich, wie ich finde
Wünsch allen einen guten Start in die Woche.

Da ich Hobbyfotograf und Linuxuser bin, verwende ich natürlich auch viel Open Source Tools zur Fotobearbeitung und Verwaltung. Welche das sind möchte ich im Folgenden mal kurz vorstellen. Die meisten werden dem versierten Linuxuser schon bekannt sein, aber ich möchte mich mit deisem Beitrag auch an die wenden, die erst mit Linux, bzw. Fotobearbeitung unter Linux anfangen.

GNU Image Manipulation Program (GIMP) – Wohl mittlerweile eines der bekanntesten Open Source Tools.

Qtpfsgui – Ein sehr gutes Programm zum errechnen von HDR Bildern. Ein Beispielfoto aus meiner Sammlung

Gthumb – Ein schöner kleiner Bildbetrachter, mit ein paar Stapelverarbeitungsmöglichkeiten. Da ich meine Fotos ohne Datenbank nur über das Dateisystem mit einer Ordnerstruktur verwalte, ist das Tool für mich genau richtig xD

UFRaw – Mein bevorzugter RAW-Konverter, läuft super mit dem Olympus RAW Format der E-510, was bei Windows nicht ohne Update ging.
UFRaw ist aber genau genommen auch nur ein Frontend für Dcraw. Gthumb beispielsweise nutzt Dcraw auch um RAW Dateien zu konvertieren und als Vorschau zu präsentieren.

Wer nicht auf Linux umsteigen kann oder will, dem kann auch geholfen werden. Gimp gibt es auch als Windows-Version und ebenso als Portable Version von Portableapps.com

In Symfony haben wir ja eine sehr hilfreiche und dem entsprechend auch Helper genannte Kapselung von JavaScript Bibliotheken. So steht auch unter anderem Prototype zur Verfügung. Nur manchmal lässt sich die API-Dokumentation der Bibliotheken nicht direkt auf die in Symfony zur Verfügung stehenden Funktionen übertragen. Ein Beispiel ist der evalScripts Parameter. Für alle die jetzt zu faul sind weiter zu lesen und schon wissen was gemeint ist: In Symfony heißt der Parameter einfach nur script

Für alle die noch nicht Wissen wofür der Parameter gebraucht wird, kommt hier ien Beispiel:

Die Funktion remote_function() ist das Symfony-Interface zur AjaxUpdater-Funktion von Prototype, mit der wir ein DOM-Element unserer Seite mit neuem Inhalt befüllen können ohne die komplette Seite neu zu laden (ist ja auch der Sinn von AJAX-Funktionen xD).

Das ganze könnte dann beispielsweise in einem Template so aussehen:

Soweit so gut. Ein kleines Problem haben wir jetzt nur, wenn der Aufruf des Moduls/Action ‘artikel/render’ in seinem Template ein JavaScript hat. Beispielsweise durch die Funktion drop_receiving_element(), weil in dem DIV mit der ID dynamicContent ein Element sein soll, welches Drag-And-Drop fähig sein soll. Standartmäßig werden nämlich JavaScripts durch den Ajax.Updater gefiltert. Abschalten lässt sich das bei dieser Prototype-Funktion durch den Parameter evalScripts. Die Symfony-Funktion remote_function() akzeptiert diesen Parameter allerdings nicht, sondern wie am Anfang schon erwähnt den Parameter script. Um diesen Parameter und folglich dann ohne JavaScript-Filter sieht der Funktions-Aufruf aus dem Beispiel dann folgendermaßen aus:

Das wars schon =)

Ich habe eben zum ersten mal ein Registrierungsformular für eine Anwendung im Symfony Framework geschrieben. So etwas kann man ja durchaus mal öfters gebrauchen daher stell ich die sfForm Klasse hier für alle zur Verfügung.

Übrigens der sfValidatorSchemaCompare funktioniert erst wenn die Felder darin mit einem Validator initiiert sind, da er ein globaler Validator ist (siehe in der Doku). In dem Beispiel werden die beiden Passwortfelder mit jeweils dem sfValidatorString und das erste noch mit dem sfValidatorRegex initiiert.

Mit dem RegEx Validator lässt sich dann schön überprüfen, ob das Passwort den eigenen Sicherheitsrichtlinien entspricht. Im Beispiel muss das Passwort mindestens ein Großbuchstabe, ein Kleinbuchstabe und eine Ziffer enthalten.
Für die Regulären Ausdrücke hier noch der Link zu einem Cheatsheet, falls noch nicht bekannt

Wenn jemand eine Adaption auf ältere Symfony Versionen versucht, dann muss er auf jeden Fall den Compare-Validator ändern in:

Da Symfony 1.2 abwärtskompatibel in diesem Punkt ist, funktionieren dort beide Varianten.

Zum Schluss wird dann mit sfValidatorPropelUnique noch überprüft ob der Username bereits verwendet wird.

Jetzt werde ich dem ganzen noch die Verifikation der E-Mail mit einem Aktivierungsschlüssel verpassen, dazu näheres dann in einem weiteren Beitrag.

Checklisten gibt es im Netz ja massig, diese enden teilweise dann in einer Schlacht an Faktoren die abgefragt werden oder sind zu allgmein gehalten. Eine Checkliste die mich wirklich überzeugt hat und wie ich finde einen Mehrwert liefert ist Symfony Check

Screenshot von symfony-check.org

Diese Checkliste fragt sämtliche Punkte ab die man in einem Symfony Projekt vor dem Deployment erledigt haben sollte. Für jeden Punkt der Liste gibt es eine gute Beschreibung, wie man diesen Punkt abhaken kann.
Beispielsweise für den Punkt ‘Change the cookie names’ wird dann genau beschrieben in welchen Config-Files Änderungen gemacht werden sollten.

Die gesamte Seite ist nur für diese eine Aufgabe optimiert und sehr übersichtlich.