![]() |
![]() |
![]() | |
![]() |
Template Segmentierung
Bisher hatten wir jeder Kategorie ein Template zugeordnet bzw. für alle Kategorien, für die kein Template definiert war, wurde von der Portalsuite automatisch das Standardtemplate benutzt. Vielleicht ist Ihnen bereits aufgefallen, daß eine globale Änderung, z.B. am HTML-Header, zur Folge hat, daß mehrere Templates an gleichen Stellen geändert werden müssen. Wir hatten bisher eine Coderedundanz in den Templates. Ein wesentliches Feature im Konzept der Portalsuite ist die Template Segmentierung. Die Segmentierung soll redundante Codefragmente vermeiden, die Modularität fördern und spätere Änderungen vereinfachen. Gleiche Codeteile aus unterschiedlichen Templates werden dazu in neue Subtemplates verlagert. Schauen wir uns die drei derzeitigen Templates an. Der Anfang ist in allen drei Templates identisch. Den Tabletag haben wir aus Übersichtlichkeitsgründen erstmal ignoriert: Template Testtemplate: <html> <head> <? PrintCSS (); ?> </head> <body bgcolor=#ffffff> <table border=1><tr><td valign=top> <? PrintCategoryTree (); ?> </td><td valign=top> <p class=Text> Dies ist ein Testtemplate.<br> Aktuell: <? echo (date (“d.m.Y“)); ?> </p><br> <? PrintCategoryArticles (); ?> </td></tr></table> </body> </html> Template Produkttemplate: <html> <head> <? PrintCSS (); ?> </head> <body bgcolor=#ffffff> <table border=1><tr><td valign=top> <? PrintCategoryTree (); ?> </td><td valign=top> <p class=Text> Dies ist die Produktseite. <br> </p><br> <? PrintCategoryArticles (); ?> </td></tr></table> </body> </html> Template Artikeltext: <html> <head> <? PrintCSS (); ?> </head> <body bgcolor=#ffffff> <table border=1><tr><td valign=top> <? PrintCategoryTree (); ?> </td><td valign=top> <? PrintArticle (); ?> </td></tr></table> </body> </html> Die Vorgehensweise ist einfach: Wir erzeugen ein neues Template, z.B. namens „HTMLHead“. Bei diesem Subtemplate spielt der Templatetyp und das Kategoriemapping keine Rolle und können leer bzw. undefiniert bleiben. In dieses neue Template wird der identische Code aus den drei Templates kopiert: Neues Template HTMLHead: <html> <head> {CSS} </head> <body bgcolor=#ffffff> Das dies kein sinnvolles bzw. vollständiges HTML-Dokument ist, spielt ebenfalls keine Rolle. Die drei bestehenden alten Templates werden nun folgendermaßen abgeändert (hier nur am Beispiel des ersten Templates gezeigt): Template Testtemplate: {TemplateInclude name=“HTMLHead“} <table border=1><tr><td valign=top> <? PrintCategoryTree (); ?> </td><td valign=top> <p class=Text> Dies ist ein Testtemplate.<br> Aktuell: <? echo (date (“d.m.Y“)); ?> </p><br> <? PrintCategoryArticles (); ?> </td></tr></table> </body> </html> Der neue Befehl „TemplateInclude“ bindet das Untertemplate „HTMLHead“ genau an dieser Stelle ein, an der vorher der HTML-Code und TCC-Befehle standen. Am Ergebnis in der Portalvorschau sollte sich nichts ändern. Selbst der zurückgegebene Quellcode sollte der gleiche wie vorher sein. Ihnen ist sicherlich jedoch sofort aufgefallen, daß wir für diesen Befehl keine PHP-Syntax mit „“ usw. nutzen, sondern eine von PHP total abweichende Syntax bei der der Befehl in geschweiften Klammern steht. Dies hat einzig und alleine technische Hintergründe. Hätten wir den „TemplateInclude“-Befehl ebenfalls als PHP-Funktion ausgelegt, hätte er sicherlich auch funktioniert. Für die PHP-Profis unter Ihnen, die später auch einmal mit Variablen und eigenen, komplexen PHP-Codes in den Templates arbeiten möchten, hätte sich jedoch ein gravierender Nachteil ergeben. Eine TemplateInclude-Funktion hätte dazu geführt, das Variablen nur für jedes Template lokal gelten (Stichwort „Variablen Scope“). Aus diesem Grund wurde der TemplateInclude nicht als Funktion, sondern in dieser speziellen Syntax eingeführt. Die Portalsuite interpretiert diesen Befehl, ohne den PHP-Interpreter dabei zu benutzen, eigenständig noch vor Ausführung durch den PHP-Interpreter und setzt die Templates entsprechend zu einem großen Template zusammen. Dieses zusammengebaute Template wird dann erst durch den PHP-Interpreter ausgeführt. Hierdurch sind alle Variablen automatisch verfügbar, auch die, die in den Untertemplates definiert werden. Zurück zur Template-Segmentierung, deren Vorteile und zu unserem Beispiel. Bei genauer Betrachtung: Zunächst einmal hat der Befehl eine optische Wirkung: Das Template ist optisch kürzer geworden. Bei großen Templates führt dies zu einer wesentlich gesteigerten Übersichtlichkeit. Und dies nicht nur in dem einem Template, sondern direkt in dreien. Ein weiterer Effekt: Änderungen im Subtemplate wirken sich auf alle drei Haupttemplates gleichzeitig aus. Spätere Änderungen lassen sich damit zeitsparend und effizient durchführen. Für den Aufbau von Portalen ist die logische Segmentierung von entscheidender Bedeutung, da sich damit sowohl der zeitliche- als auch der quantitative Codeaufwand erheblich reduzieren läßt. Überlicherweise werden Menüs, Kopfzeilen, Nachrichtenspalten u.ä. in eigene Untertemplates ausgelagert, um von verschiedenen Stellen wieder eingebunden zu werden. [zurück] - [bookmarken] - [Druckversion] - [Weiterempfehlen] - [Kontakt] - [Impressum]
Copyright © 2000-2012 by Portunity GmbH - Alle Rechte vorbehalten. |
![]() ![]() Providing unter:
http://portunity.net
![]()
|
|||||||||