Kein Stolperstein, aber eine für mich neue Richtlinie: keine einzige PHP-Script-Datei enthält das PHP-Schliessen-Tag ?> am Dateiende. PHP scheint das zu tolerieren und beendet das Script normal. Der Grund für diese Richtlinie ist recht praktisch, denn hier kann es gar nicht erst passieren, dass White-Spaces (Leerzeichen, Zeilenumbrüche u.ä.) nach dem Schliessen-Tag dafür sorgen, dass später gesendete Header-Informationen nicht mehr angenommen werden.

In dem Tutorial wird eine Beispiel-Applikation in Form eines Gästebuches gebaut. Als Datenbank wird SQLite verwendet. Dafür musste ich das Debian-Paket php5-sqlite nachinstallieren.
Ausserdem musste der Webserver so konfiguriert werden, dass das public-Verzeichnis als Web-Root-Verzeichnis fungiert. Ich hatte das Test-Projekt erst in einem Unterverzeichnis laufen, was aber zu einem Fehler in der Applikation führte.
Als nächstes musste ich das Verzeichnis für die Datenbank anlegen und mit entsprechenden Rechten versehen, denn sonst konnte das load-Skript nicht die Datenbank anlegen.
Beim Anlegen der Model Klasse habe ich wegen eines Schreibfehler des Tutorial-Skript-Schreibers natürlich ein falsches Verzeichnis gewählt: statt application/model/GuestBook.php muss der Pfad korrekterweise application/models/GuestBook.php lauten – nur ein fehlender Buchstabe, aber dennoch fatal.
Das kommt bei einem der nächsten View-Skripte nochmal vor, ist aber im Gegensatz zu vorher ziemlich offensichtlich: application/views/scipts/guestbook/sign.phtml.
Und schliesslich soll man die zwei Methoden signAction() und _getGuestbookForm()
zur GuestbookController-Klasse hinzufügen, die sind aber in der selben Form bereits vorhanden – eine doppelte Deklaration der Methoden lässt PHP nicht zu und bricht natürlich ab.

Wenn man alle diese Hürden überwunden hat, ist die erste Zend-Applikation fertig und das Tutorial zuende. Leider kann man aber keinen Eintrag ins Gästebuch schreiben, da nach erfolgreichem Eintragen (nur 20 Zeichen und lustiges ASCII-CAPTCHA), ein Application-Error “passiert”: SQLSTATE[HY000]: General error: 8 attempt to write a readonly database.
Das liegt daran, dass ich das load-Skript als Benutzer ausführen musste (ich hatte dafür sogar extra das php5-cli Paket installiert). Die dadurch erstellte DB-Datei hatte dadurch natürlich die falschen Rechte, denn bei Zugriff über Webbrowser, muss der Webserver Zugriffsrechte auf die Datei haben. Bei mir reichten chown ric:www-data guestbook-dev.db und chmod ug+rw guestbook-dev.db.
Trotzdem bekommt man bei einem neuen Eintrag immer noch eine Fehlermeldung: SQLSTATE[HY000]: General error: 14 unable to open database file . Das war diesmal aber mein eigener Fehler, denn ich hatte vergessen, das Verzeichnis db der korrekten Gruppe zuzuweisen. Ich hatte es für data gemacht, aber nicht das R-Flag (rekursiv) bei chown gesetzt.

Jetzt funktioniert meine erste Zend-Applikation – und bisher sind meine Erwartungen zu Struktur und Mächtigkeit nicht enttäuscht worden. Das Tutorial hat zwar ein paar Schwachstellen, aber im Grossen und Ganzen bekommt man einen guten Einblick in die Funktionsweise des Frameworks.
Wenn man sich den Stress des Selbst-Zusammenbauens dieser Tutorial-Applikation nicht geben will, kann natürlich auch den Code als fertiges Paket herunterladen. Einen Link dazu gibt es auf jeder Seite des Tutorials.

Ich nehme mir jetzt mal das 162 Seiten starke Dokument “Quick Start Tutorials” vor.

Hello World
Wir fangen an – wie kann es anders sein – mit dem klassischen “Hello World” Projekt. Es wird einem schön Schritt für Schritt gesagt, was man tun muss. Diese Schritte werden teilweise von Screenshots begleitet, wobei ich das Gefühl habe, dass diese Bilder oft nicht zum aktuellen Abschnitt passen, bzw. dass die passenden Bilder etwas zu spät kommen. Aber das sollte einen nicht aufhalten.
Eine Stelle, über die ich gestoplert bin, weil nicht explizit darauf hingewiesen wurde (und das passende Bild dazu natürlich erst einen Absatz später gezeigt wurde), ist die Angabe des Strings in “Source Name”, nachdem man “Source Type” auf “Expression” gesetzt hat: ich hatte nämlich die Anführungszeichen vergessen, was zu einem PHP-Fehler führte. Das ist mir aber auch erst klar geworden, nachdem ich mir den generierten Code angeschaut hatte.
Gravierender ist der Punkt, den ich gestern schon bemängelte: Die “Live Page”-Option funktioniert einfach nicht. Die Adresse, die in der IE-Fehlermeldung als falsch erklärt wird, funktioniert, wenn man sie manuell in einem Browser (auf der selben Maschine!) aufruft. Diverse Forums-Einträge zeigen, dass ich nicht der einzige bin, der das “Hello World”-Tutorial nicht komplett erfolgreich beenden kann. Lösungen werden keine geboten. Eine finale Antwort eines ellenlangen Threads war nicht schlecht, an die ich mich wohl auch halten werde: “I never use that option…“.

Somit ist das erste Tutorial quasi fertig und das End-Ergebnis ist “lauffähig”, wenn auch nicht alles innerhalb CCS so funktioniert hat, wie beschrieben.

Employee Directory
Das nächste Tutorial soll ein Mitarbeiterverzeichnis erzeugen, wobei zunächst erstmal diverse Projekteinstellungen vorgestellt werden, darunter auch die Datenbankverbindungen. Da CodeCharge mit vielen verschiedenen Programmiersprachen und auch Datenbanksystemen arbeiten kann, sehen hier leider die Projekteinstellungs-Screens teilweise recht unterschiedlich aus. Auch wird auf ein paar Datenbankverbindungs-Details eingegangen, die es in meinem Fall gar nicht gibt…ein wenig irritierend ist das schon.
Nachdem man alle Projekteinstellungen durchgegangen ist, darf man jetzt den “Grid Builder” verwenden, um vermutlich eine Tabelle mit Daten aus der Datenbank anzuzeigen. Um die darzustellenden Felder auszuwählen, kann man den Visual Query Builder verwenden, der mit CCS kommt. Hier soll man zwei Tabellen auswählen…die ich natürlich nicht habe. Wer den ersten Teil dieses Testberichts gelesen hat, mag sich vielleicht erinnern, dass ich gestern vor einem ähnlichen Problem stand: die Datenbank ist natürlich leer! Es gibt keine einzige Tabelle! Auch im Tutorial ist dazu nichts erwähnt. Zumindest ist mir nichts aufgefallen und ich werde es wohl übersehen haben, wenn es beschrieben wurde.
Ein Blick ins Forum (ok, das war gelogen, mehrere Blicke) und die Lösung findet sich in einem Antwort-Post eines YesSoftware-Forum-Moderators, der einem anderen verzweifelten Tutorial-Anwender erklärt, die Tabellenstruktur befünde sich hier: C:\Program Files\CodeChargeStudio3\Examples\Intranet\Intranet_MySQL.sql. Und das stimmt! Mein Gott, Walter! Warum denn nicht gleich so
Ab hier geht alles recht relativ leicht. Besonders schön sind die Einstellmöglichkeiten für die Sortierung der Tabelle und man kann diverse Seiten-Navigationsdesigns auswählen. Ausserdem gibt es für das Seitenlayout unzählige Styles aus denen man auswählen kann. Das hat schon was – ohne so ein Tool würde man eine nicht unerhebliche Zeit allein zum Zusammenschustern von einigermassen lesbaren Tabellen benötigen.
Die weiteren Schritte bestehen hauptsächlich darin, die Such-Felder mit der HTML-Tabelle und den DB-Tabellen zu verknüpfen. Wenn man damit fertig ist, steht das Publishen an.
Wenn man aber, wie ich, den Security-Teil des Tutorials übersprungen hat, wie es der Text einem vorschlägt, wird man vor einem Problem stehen. Man hat nämlich laut Tutorial eine Login-Seite eingerichtet und die Seite mit der Tabelle auf Restricted gestellt, damit nur eingeloggte User mit einem bestimmten Level diese Tabelle sehen dürfen. Dummerweise habe ich aber eben jenen Teil übersprungen, der die projektweiten Userdaten definiert. Somit funktioniert das Login-Formular gar nicht und man kann seine tolle Tabelle nicht anschauen
Gut ich bin ja nicht auf den Kopf gefallen und habe diese Einstellungen noch vorgenommen und jetzt kann ich mir die sehr hübsche, funktionsreiche und eigentlich total easy erstellte Tabelle anschauen und darin blättern, bzw. suchen. Genial – ich bin wirklich begeistert!

Spätestens jetzt kann ich wirklich sagen, dass CodeCharge ungeheuer mächtig ist und einem wirklich verdammt viel Arbeit abnimmt, sobald man sich darin zurechtfindet.
Ich habe bis jetzt wohl nur an der Oberfläche gekratzt, denn es stehen mir noch unzählige Builder zur Verfügung, von denen ich noch nichts weiss. Ich bin wirklich gespannt, was da noch für Tools versteckt sind.

Seit dem habe ich mit CCS nichts mehr am Hut gehabt. Letzten Monat konnte ich aber bei dem bereits erwähnten Kunden kurz beim Arbeiten mit CCS über die Schulter schauen, wobei ich mir noch kein so rechtes Bild davon machen konnte.

Daher jetzt ein erster Testbericht:
Das CodeCharge Studio 4 lässt sich als 20-Tage-Trial-Version herunterladen. Die 20 Tage beschränken sich anscheinend tatsächlich auf Arbeitsdauer und zählt nicht einfach ab Installation die Kalendertage herunter. Zumidest lässt es sich jetzt starten, obwohl ich das Studio bereits vor einigen Wochen installiert hatte und mangels Zeit noch nicht benutzten konnte.

Erstes Problem: ich kann kein Projekt-Verzeichnis auf einem Netzlaufwerk verwenden! In meinem Fall ist es sogar eigentlich nur ein Shared-Folder, zu meinem Linux-Host-System, da ich CCS in einer virtuellen Windows-Maschine laufen lasse. Aber die Doppel-Slashes scheinen CCS zu stören:

Nagut, halb so wild, wird eben ein lokales Verzeichnis benutzt
Das Studio kommt bereits mit diversen Demos geliefert. Ich habe mir den “Task Manager” zum Testen ausgesucht. Nach erfolgreichem Anlegen des Projektes sehe ich nun auf der linken Seite eine Übersicht aller Elemente des Projektes in Form eines Trees, aufgeteilt in Pages, Diagrams, Connections, Ressources und Common Files. Oben gibt es ein recht übersichtliches Menü, sowie zwei Icon-Bars, ganz so wie man es zum Beispiel aus MS Word kennt. Rechts gibt es eine Toolbox und ein Properties-Fenster, unten sitzt eine Message-Box, vermutlich für Warnungen und Fehlermeldungen im Code und der grosse mittige Bereich ist für den Code des jeweiligen ausgewählten Dokumentes vorgesehen:

Im Grossen und Ganzen sieht es nach einer klassischen Aufteilung des Bildschirms aus, wie bei Microsofts “Visual Studio” oder der Developer IDE der Eclipse Foundation. Letztere war übrigens die vergangenen Jahre das Entwicklungs-Werkzeug meiner Wahl.

Zweites Problem: Routinemässig richte ich für jedes meiner Projekte eine Versionskontrolle ein. Früher ging das für mich unter Visual Studio mit SourceSafe, später unter Linux mit CVS und inzwischen mit SVN, welches gegenüber CVS moderner ist. CCS bietet auch eine “Source Control” an, welche sich aber anscheinend standardmässig auf CVS stützt. Jedenfalls wird bei mir gleich das Fehlen der “Cvs EXE” bemängelt, es wird mir aber die Angabe einer Applikation angeboten:

Ich sehe hier auf die Schnelle leider keine Möglichkeit SVN (bzw TortoiseSVN) innerhalb von CodeCharge zu benutzen. Da sich TortoiseSVN sowieso direkt in Windows integriert, sehe ich hierbei aber keinen übermässigen Nachteil, wobei es schön gewesen wäre, das innerhalb von CCS zu haben.

Drittes Problem: ist eigentlich gar kein Problem. Bevor ich irgend etwas von den Programmier-Tools ausprobieren will, versuche ich, das Demo-Projekt so wie es ist auf meinem Apache2-Entwicklungsserver zum Laufen zu bekommen. Dafür habe ich folgende Publish-Optionen: Intranet und FTP. Na toll! Mit Intranet wird wohl ein Netzlaufwerk oder ähnliches gemeint sein, was quasi das erste genannte Problem adressiert. Will ich jetzt aber nicht, weil mein Produktionsserver, wenn ich einen benutzte, nicht im Intranet sitzen würde! FTP – hmm. Wer benutzt heutzutage noch FTP bitteschön? Ok, viel zu viele, aber das ist doch asbach-uralt und unsicher wie sau! Aber hier war ich wohl etwas zu voreilig, denn hinter FTP versteckt sich bei CCS auch die Möglichkeit, eine sichere Verbindung zu verwenden, sprich: SFTP! Das ist es, was ich will!

Viertes Problem: ist kein CodeCharge-spezifisches Problem, aber es kostete mich dennoch einen haufen Zeit. Und zwar geht es um die Datenbank-Verbindung. In meinem Fall: MySQL – natürlich unter Linux. Dafür musste ich auf meiner Windows-Maschine erstmal einen ODBC-Treiber für MySQL installieren und die Datenbank-Verbindung in der Windows-Verwaltung einrichten. Das ging natürlich nicht auf Anhieb. Jedesmal dieser dämliche 10061-Fehler, obwohl ich für den DB-User extra _alle_ Hosts zulasse und keine Firewall laufen lasse. Naja, im Endeffekt war es die Zeile mit “bind-address”, die ich aus der my.cnf entfernen musste UND ein Neustart der kompletten MySQL-Applikation, ein einfaches Reload reichte leider nicht, worauf ich auch erst nach einigen Versuchen gekommen war…

Jetzt kann ich endlich das Demo-Projekt auf den Test-Server spielen und die DB-Verbindung funktioniert sogar sowohl im Entwicklungs-Modus als auch im Test-Modus und ich kann das Projekt über den Browser aufrufen. ABER: die Tabellen fehlen noch. Die Anwendung läuft, spuckt aber Meldungen aus, dass die Tabelle “tasks” nicht existiert. Das kann ich sogar bestätigen – mit einem kurzen Blick auf die Datenbank: es existiert keine einzige Tabelle.

Fünftes Problem: Man kann die Home-Page des Projektes innerhalb von CodeCharge öffnen – übrigens einfach ein integrierter Internet Explorer vom System. Jedenfalls kommen nach dem Aufruf im Message-Fenster ein paar Meldungen, die aussagen, dass der Content generiert wird und zusätzlich poppt ein Status-Fenster mit Fortschrittsbalken auf. Das ist aber so schnell wieder weg, dass ich nicht sehen kann, was eigentlich da fortschreitet, es sieht aber so aus, als ob das der normale Publish-Vorgang wäre. Sofort erscheint eine Fehlermeldung:

Sehr witzig! Die Adresse war am Anfang tatsächlich falsch, aber nachdem ich die passende Option in den Projekteinstellungen korrigiert hatte, kam der selbe Fehler wieder, nur diesmal mit der _richtigen_ Adresse
Im Browser (IE und FF), auf der selben Maschine, lässt sich genau diese Seite nämlich öffnen! Tja, was nun?
Könnte sein, dass dieser Fehler damit zusammenhängt, dass keine Tabellen generiert worden sind.
Ich komme jetzt erstmal nicht weiter. Schauen wir mal, wie es morgen aussieht