|| Kurze [[Typo3]]-Dokumentation || Typo3Lösungen || [[Typo3/FORUM]] || <!> || <<TableOfContents>> == Warum diese Seite == Sammlung von praktischen Tools, und zwar kostenlose Software. Einfach als Ergänzung zu den Anleitungen, die es schon gibt. Und per WikiWiki, weil damit leicht aktualisierbar ;) Nur '''für Fortgeschrittene''' gedacht, die schon etwas Übung in PHP haben. Die große und komplexe Extensions erstellen wollen. siehe auch {de} http://typo3faq.net == Hilfe: PHP Coding Standards/ Dokumentierung == Der einzige Standard, an den man sich wirklich halten muss, ist natürlich der von Kaspar. Der Rest ist nice-to-have für komplexe Projekte. * '''Typo3-Standard''' Klassen-Benennung und Funktionen-Benennung: [[http://typo3.org/documentation/document-library/doc_core_cgl/Introduction-52/|Direktlink in Kaspars Doku auf typo3.org]] * '''doc-Standard''' Kommentare im javadoc-Stil für den phpDocumentator[[http://www.phpdoc.org/docs/HTMLSmartyConverter/default/phpDocumentor/tutorial_phpDocumentor.howto.pkg.html#basics.tags|phpdoc.org]] * '''PHP-Standard''' [[http://alltasks.net/code/php_coding_standard.html|alltasks.net]] * '''Projekt-Management-Standard''' [[http://www.tldp.org/HOWTO/Software-Proj-Mgmt-HOWTO/starting.html#CHOOSEVERSIONING|www.tldp.org]] Wenn man selbst noch am core "Hand angelegt hat" (was man ja eigentlich nicht tun sollte) und möchte auf Typo3 3.6 upgraden, dann muss man natürlich wissen, WO man WAS geändert hat. Damit man sauber umschichten kann. Ohne Bauchschmerzen. Im letzten Projekt haben wir es so gemacht: {{{ 1. Im Source-Code die Änderungen markieren: {@internal DanielB 2004/5 Änderung xxx damit yyy} Das ist übrigens der Coding-Standard für phpdoc bzw. "phpDocumentator". }}} {{{ 2. Und nun alle Änderungen anzeigen: Mal angenommen der Pfad ist "/home/virtual/site2/fst/var/www/html/". grep -r -i {@internal /home/virtual/site2/fst/var/www/html/typo3conf/* grep -r -i {@internal /home/virtual/site2/fst/var/www/html/typo3/* Kann man natürlich gut als Shell-Skript in bin ablegen }}} == Hilfe: Bug Tracker (OpenSource und FreeSoftware) == * der vielleicht beste BugTracker: [[http://www.incogen.com/index.php?type=General¶m=bugport|INCOGEN's BugPort System]] Der große Vorteil im Vergleich zu bugzilla, dass er wesentlich einfacher bedienbar ist! * [[http://www.mantisbt.org/demo.php|Mantis]] (Benutzergruppe visitor-reporter-updater-developer, Dateianhang für Screenshots, 15 Details pro Bug, mehrere Sprachen, Farben je nach Status, Kategorien) * phpBugTracker: http://phpbt.sourceforge.net/demo/ (20 Details pro Bug) == Hilfe: Objektorientiertes Programmieren == http://www.php.net/manual/de/language.oop.php {{{ // das ist wesentlich besser als "Spaghetti-code" // Ein paar Beispiele (völlig aus dem Zusammenhang gerissen): $Fritz = new VereinsMitglied; // neues Objekt instanziieren $Fritz->load("Fritz"); // select an Datenbank um Datensatz zu holen $Fritz->viewSingle(); // zugehöriges HTML-Template nutzen und Datensatz anzeigen $Fritz->save(); // geänderen Datensatz per update an Datenbank schicken }}} == Tool "PHP Doc" - Typo3 API übersichtlich und durchsuchbar == Ohne den richtigen Überblick kann man das Extension-Programmieren vergessen. Aber es gibt Hilfe. Online verwenden: http://typo3doku.ueckermann.de/ '''Dank an Nico Ueckermann ;) ''' Selbsterstellen: ist auch kein Problem. Man nehme das Tool Google:PHPdoc+download oder die bessere Alternative Google:Doxygen+download {{http://typo3doku.ueckermann.de/doxygen.png}} == Tool "Argo UML" == Mit UML (DseWiki:UnifiedModelingLanguage) lassen sich bessere und komplexere Extensions erstellen. Einfach deshalb, weil man nicht so schnell den Überblick über Klassen, Funktionen und Workflow verliert. -- Zumindest das Klassendiagramm sollte man entwerfen, bevor man mit Coden beginnt. Google:Argo+UML+download ist kostenlos. Es lohnt sich ein Google:UML+Training+Tutorial durchzuarbeiten. Was auch ganz nett ist: PHP Doxygen bietet auch graphischen Überblick. Ein Klassendiagramm. Zwar nicht UML aber immerhin. Man verrennt sich dann nicht mehr so leicht ;-) == Tool "Visual Paradigm for UML" == http://www.visual-paradigm.com/vpuml.php == Tool: Entwicklungs-Umgebung (kostenlos) == '''PHP Eclipse:''' Google:PHP+Eclipse hat eine große Zahl an Features, und wird ständig weiterentwickelt. [[http://www.phpeclipse.de/images/screenshot.png|Großer Screenshot]] - Ist noch immer eine Alpha-Version. Siehe auch http://eclipse.php.cd/ '''PHPEdit:''' ''Falls man Windows NT verwenden sollte, auf keinen Fall eine 0.7.x-Version herunterladen. Denn es werden einige Funktionen der shell32.dll verwendet - und die rückt Micros*ft nicht mehr heraus.'' http://www.phpedit.net/ {{http://www.phpedit.net/products/PHPEdit/images/shot_front.gif}} - Vorteil gegenüber PHP Eclipse: stable Version - Vorteil gegenüber standard-Editor: integrierter Debugger - Vorteil gegenüber anderen PHP-Editoren: Man kann Makro-Skripte für den Editor schreiben (Mehr als 150 Kommandos verfügbar) - Vorteil gegenüber anderen PHP-Editoren: Schnittstelle für Plugins vorhanden (Google:phpedit+plugin) '''PHP Coder:''' http://www.hotscripts.com/cgi-bin/review.cgi?ID=9092 - unter anderem mit automatischem Auto-complete, debugging mit breakpoints '''Maguma:''' http://www.maguma.com/de/index.html Die kostenlose Version ist recht interessant. == Tool "PHP Unit" - Automatisierung von Tests == Sinn von Unit-Tests mit Google:PHP+Unit+download ist es, dass man auf das zeitraubende Debuggen oft verzichten kann. Denn man überlegt sich die passenden "Testfälle" (siehe auch DseWiki:KategorieTesten) und kann dann in aller Ruhe zusehen, wie der Computer für einen testet. Am nützlichsten ist es, Tests zu schreiben, wenn man beginnt, eine Extension zu schreiben. Wenn man etwas hinzufügen möchte, schreibt man als erstes einen Test. Während man den Test schreibt, überlegt man sich, was die neue Funktion bzw. das Stück Code tun soll. Den Test zu schreiben führt dazu, dass man sich auf die Schnittstelle konzentriert, anstatt die Implementierung. Der Code ist dann fertig, wenn der Test funktioniert! Und wieviel testen? Nur das, was leicht schiefgehen kann. Wie testen? Randbedingungen prüfen, prüfen ob Ausnahmen abgefangen werden. == Hilfe: Refactoring - Optimierung von PHP Scripts == Sinn vom Faktorisieren ist Lesbarkeit von Scripts, und das Bauen von "praktischen Bausteinen", die sich leicht wieder verwenden lassen. Ein DseWiki:RefactoringBeispiel kann man recht leicht aus der Java-Welt nach PHP übertragen. Wann ist es sinnvoll "übel riechenden Code" zu säubern: * Duplizierter Code -- ''Das heißt man findet die gleiche Codestruktur an mehreren Stellen im Programm. Mit jeweils nur wenig Unterschied.'' * Lange Funktion -- ''Das heißt eine Funktion, ist so lang, dass man nur mit Mühe sehen kann, was darin tatsächlich passiert.'' * Große Klasse -- ''Das heißt, die Klasse hat viel zu viele unterschiedliche Aufgaben. Man erkennt dies an einer großen Zahl an Funktionen, manchmal auch an einer großen Zahl an klassen-eigenen Variablen.'' == Hilfe: Typo-Script-Features benutzen (wichtiger Teil der Typo3API) == Verwendung von !TypoScript-Funktionen (Typo3TypoScript) '''tslib_cObj''' auch genannt '''tslib_content''' Im Prinzip ist die Klasse tslib_cObj (neben tslib_pibase) die wichtigste API-Klasse für Frontend Plugins. Durch ihre Hilfe kann man nämlich nahezu alles, was in !TypoScript möglich ist, in seinen eigenen Extension-Scripts anwenden. Um die Funktionsweise dessen zu verstehen, braucht es allerdings etwas Zeit und Mühe, die der Extension-Programmierer aber unbedingt investieren sollte, es lohnt sich! Als erstes gilt es zu verstehen, was !TypoScript intern eigentlich wirklich ist. Eine perfekte Dokumentation dazu gibt es von Kasper: "!TypoScript Syntax and In-depth Study" http://typo3.org/doc.0.html?&tx_extrepmgm_pi1[extUid]=264&cHash=3553a3af05 <!> Erst wer diese Dokumentation durchgelesen hat, wird die benutzung der tslib_content-API-Funktionen wirklich verstehen. ''Hier ein Beispiel:'' Oft möchte man in seiner Extension ein Bild ausgeben lassen, und hat dafür mit dem Kickstarter die tt_content-Tabelle um ein Upload-Datenbankfeld vom Typ "file" erweitert. Angenommen das Feld hieße "bild", und das Plugin sei als Content-Element auf der Seite eingebunden, so würde man den Namen der Bilddatei über $this->cObj->data['bild'] bekommen. Wenn man nun einen Image-Tag für dieses Bild im Frontend ausgeben möchte, so könnte man innerhalb der main-funktion der extension einfach folgendes der Variablen $content hinzufügen: $content .= '<img src="uploads/tx_meineextension/'.$this->cObj->data['bild'].'" alt="bild">'; So würde man den Image-Tag hardkodiert in den Code reinschreiben, es ist sozusagen der "quick-and-dirty"-Weg. Allerdings wird dann das Bild immer in der Originalgröße angezeigt, und es wird somit möglicherweise den Bildschirmrand überschreiten. Spätestens, wenn man das Bild auf eine maximale breite von 200 Pixel rendern möchte, ist es an der Zeit, die API-Funktionen von Typo3 zu nutzen. Der erste Schritt dazu ist herauszufinden, wie man eine maximale Größe eines Bildes mit !TypoScript festlegen kann. Dazu kuckt man als erstes in der TSRef unter "IMAGE", und findet dann das property ".file", welches vom Typ imgResource ist. Nun kuckt man weiter im Kapitel "imgResource", und findet da das, was wir suchen, nämlich "maxW", womit man die maximale Breite eines Bildes angeben kann. Das !TypoScript (Typo3TypoScript) für ein Bild mit maximaler Größe wäre also: {{{ unserbild = IMAGE unserbild.file = uploads/tx_deineextension/bild.jpg unserbild.file.maxW = 200 }}} OK, wer "!TypoScript Syntax and In-depth Study" ordentlich gelesen hat, wird wissen, dass das ganze intern so aussehen würde: {{{ $TS = array( 'unserbild' => 'IMAGE', 'unserbild.' => array( 'file' => 'uploads/tx_deineextension/bild.jpg', 'file.' => array ( 'maxW' => '200' ) ) ) }}} Der wirklich relevante Teil davon, ist aber nur folgendes: {{{ $conf = array( 'file' => 'uploads/tx_deineextension/bild.jpg', 'file.' => array ( 'maxW' => '200' ) ); }}} Die Funktion aus tslib_content, die wir nutzen müssen, heißt IMAGE(). Der einzige Parameter, der an die Funktion übergeben werden muss, ist das Array $conf. Also hier nun endlich der komplette Code, den wir brauchen, um das Bild von der API-Funktion IMAGE() generieren zu lassen: {{{ $conf = array( 'file' => 'uploads/tx_deineextension/'.$this->cObj->data['bild'], 'file.' => array ( 'maxW' => '200' ) ); $content .= $this->cObj->IMAGE($conf); }}} ''Wenn jemand Zeit findet, dieses kleine Tutorial mal ein bischen zu cleanen, waere ich ihm sehr dankbar! ...cheers... Ingmar Thanx, Ingmar!! Finde ich prima, dass Du das geschrieben hast --DanielBrüßler '' == Hilfe: Weitere Anwendungsmöglichkeiten für die Typo3-API == * Anwendungsbeispiel zur Klasse '''tslib_pibase''' {{{ // Einbinden in eigene Extension require_once(PATH_tslib."class.tslib_pibase.php"); class tx_EXTENSIONNAME_pi1 extends tslib_pibase { ... } }}} {{{ // Das SELECT-Statement kann automatisch zusammengebaut werden // Die Parameter werden im internal-Array gehalten. z. B. internal["orderBy"] $query = $this->pi_list_query("tx_EXTENSIONNAME"); $res = mysql(TYPO3_db,$query); }}} {{{ // URL-Parameter prüfen. Zum Beispiel ob ein submit-Button geklickt wurde if(isset( $this->piVars['submit_button']) ) { ... } }}} * Anwendungsbeispiel zur Klasse '''t3lib_div''' {{{ // URL-Parameter prüfen. Alternative. Zum Beispiel ob ein submit-Button geklickt wurde // Es werden sowahl GET, als auch POST Parameter geprüft - Vorrang hat POST ! if(isset( t3lib_div::GPvar('submit_button') ) { ... } }}} * Anwendungsbeispiel zur Klasse '''tslib_fe''' - http://www.typo3.net/viewtopic.php?t=5381&highlight=tslib*+encryptemail {{{ // Emailadressen "verschlüsselt" auf die Webseite setzen. Wie auf www.typo3.org tslib_fe::encryptEmail ( $string, $back = 0 ) }}} * Anwendungsbeispiel zur Klasse '''t3lib_TStemplate''' {{{ // Datei hereinladen t3lib_TStemplate::fileContent ( $fName ) }}} = Diskussionsbereich, Anregungen = ---- KategorieTypo3