Seit ein paar Wochen arbeite ich an einem Projekt, welches die Vorgabe hat, komplett in CodeCharge enwickelt zu werden. Dabei bin ich immer wieder an die Grenzen dieses mächtigen Werkzeuges gestossen. Ein häufiges Problem ist für mich, die Custom-Block-Möglichkeiten der Template-Klasse an Stellen zu verwenden, die CodeCharge anscheinend nicht dafür vorgesehen hat und daher nicht ohne weiteres zulässt.

Es gibt drei unterschiedlich zu behandelnde Fälle, Custom Blocks zu plazieren, soweit ich das überblicke:

• in der obersten Ebene, ausserhalb aller Components
  Hier gibt es gar keine Probleme. Man kann seine Custom Blocks einfach definieren:

  <!-- BEGIN mein_custom_block -->
     mein html code undso mit {meine_variable}
  <!-- END mein_custom_block -->
  

  und per benutzerdefinierten PHP-Code z.B. im “Before Show”-Event der Seite so verwenden:

  global $Tpl;
  $first = true;
  foreach ($mein_array as $element)
  {
     $Tpl->SetVar("meine_variable", element);
     $Tpl->Parse("mein_custom_block", !$first);
     $first = false;
  }
  

• innerhalb eines Blockes (z.B. Row) einer Component (z.B. Grid)
  Das funktioniert fast genauso. Man muss der Template-Klasse nur die eigene Block-Variable nennen:

  global $Tpl;
  $first = true;
  $Tpl->SetBlockVar("mein_custom_block","");
  foreach ($mein_array as $element)
  {
     $Tpl->SetVar("meine_variable", element);
     $Tpl->Parse("mein_custom_block", !$first);
     $first = false;
  }
  

  Diese ersten beiden Fälle sind auch dokumentiert: Working with Custom Template Blocks

• innerhalb eines Panels (bzw. Update-Panels)
  Will man einen Custom-Block innerhalb eines Panels verwenden, was ja das Mittel der Wahl sein soll, sobald man ganze Bereiche der Webseite einfach ein bzw. ausblenden muss (z.B. wegen Zugangsberechtigungen), dann funktionieren die ersten beide Vorgehensweisen nicht mehr. Custom-Blöcke werden hier nicht berücksichtigt, ja sogar vor dem Anzeigen entfernt.

  Das liegt daran, dass der Template-Klassen-interne Zeiger auf der darüberliegenden Ebene stehen bleibt, sobald man sich im “before show”-Ereignis des Panels befindet.
  Die Abhilfe dazu sieht so aus, dass man

  1. sich die aktuelle Position des Template-Klassen-Zeigers merkt (in unserem Fall müsste “/main” darin stehen),
  2. dann den Zeiger mit dem Panel-Pfad-Überschreibt (z.B. “/main/Panel mein_panel”),
  3. hier wie bei den anderen beiden Fällen, die Template-Operationen durchführt und
  4. danach den Zeiger wieder auf den ursprünglichen Punkt richtet (also in unserem Beispiel wieder auf “/main”).

  global $Tpl;
  // (1):
  $aktueller_zeiger = $Tpl->block_path;
  // (2):
  $Tpl->block_path = $aktueller_zeiger . "/Panel mein_panel";
  // (3):
  $first = true;
  foreach ($mein_array as $element)
  {
     $Tpl->SetVar("meine_variable", element);
     $Tpl->Parse("mein_custom_block", !$first);
     $first = false;
  }
  // (4):
  $Tpl->block_path = $aktueller_zeiger;
  

  Benötigt man übrigens in seinem Panel lediglich eine Template-Variable (also {meine_variable}) ohne einen Custom-Block, so braucht man sich nicht mit diesem Workaround abgeben. Template-Variablen alleine funktionieren innerhalb von Panels wie gewohnt und völlig problemlos.
  

Zusammengefasst: Das Problem lag daran, dass die externen JavaScript-Dateien nicht geladen werden konnten, stattdessen wurden HTML-Seiten durch ungünstig gewählte mod_rewrite-Regeln geladen, die natürlich einen “syntax error” erzeugten.
Das steht dem Fehlverhalten bei leerem src-Attribut in script-Tags nicht entgegen, denn der Webserver gibt normalerweise eine Standard-Seite (z.B. index.html) zurück, wenn nur ein Verzeichnis aufgerufen wird (bei leerem src-Attribut wird von Webserver automatisch der komplette Pfad der Basis-Seite ohne Dateiname verwendet), oder eben, falls nicht vorhanden, eine Fehler-Seite, die meistens HTML-Code beinhalten und eben nicht JavaScript.

Die Lösung: Man muss nur dafür sorgen, dass alle eingebundenen JavaScript-Dateien auch tatsächlich geladen werden, bzw auch den Inhalt haben, der tatsächlich gebraucht wird.
Bei uns hiess das, die mod_rewrite-Regeln soweit anpassen, dass solche Script-Dateien nicht umgeleitet werden. CodeCharge-seitig wäre das zu aufwendig geworden, denn es handelte sich hier um HTML-Code der von CodeCharge generiert wird und nur schwer beeinflusst werden kann, ohne dass bei neuem Generieren die Anpassungen wieder überschrieben geworden wären.

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