Off-Topic: Smarty-Aufbau

[k00ni]

Parallel zu http://www.powie.de/cms/forum/showthread.php?id=22960\" rel=\"external nofollow\">dieser Diskussion, wollte ich einfach mal frech fragen, was das bringen soll. Ich mein, dies würde bedeuten, dass man große Teile der Skripte umschreiben kann.
Wer soll das machen? Ich will hier keine Diskussion über die Zeitaufwändungen von Powie anfangen. Ich bin nun schon seit über einem halben Jahr sehr aktiv hier in der Community und merke, dass es neben Powie und mir, vielleicht ein oder zwei Leute gibt, die wirklich aktiv mit PHP entwickeln. Der Rest ist Nutzer. (Wogegen ich auch nichts sage). Es wird, wie immer, wieder nur an Powie hängen bleiben.
Ich meine, bevor man sich groß Gedanken über etwas macht, was meiner Meinung nach nicht sehr vorrangig ist. Sollte man eher an den Kanten weiter feilen, die schon bestehen: Lokalisierung des pSys, Datenbankklassen für DB2 und MySQL. Was ist damit?
 
Grüße

Natürlich bleibt die Umstellung am Entwickler hängen, aber man muss auch die Vorteile sehen - eine Designanpassung, die im Vergleich zu den CSS Tricksereien unglaublich fortschrittlich wirkt.
Achja, am Ende steht natürlich noch viel sauberer Code.

Ich stimme inch unvorbehaltlich zu.

Ich meine, bevor man sich groß Gedanken über etwas macht, was meiner Meinung nach nicht sehr vorrangig ist. Sollte man eher an den Kanten weiter feilen, die schon bestehen: Lokalisierung des pSys, Datenbankklassen für DB2 und MySQL. Was ist damit?[/quote]
IMO ist für eine saubere Lokalisierung erstmal eine Abstrahierung nötig. Ob man die dann mit einem Templating-System wie Smarty lösen möchte, ist dann letztlich eine Frage des Geschmacks.

[Powie]

Ich stelle mal fast in Frage das \"Smarty\" wesentliche Vorteile dabei bringt ein System mit \"Styles\" und Farbdesigns zu versehen.
Ich habe in den letzten Wochen eine Menge mit Smarty ausprobiert. Es ist echt ein geniales System! Super um HTML vom PHP abzutrennen, einen logischen Aufbau zu erzeugen, und es macht ja auch eine Menge Dinge einfacher. Soweit ich es bisher gesehen habe, würde es sich problemlos in das pSys integrieren lassen, auch mit Language Support etc.
Aber: Mir stellt sich die Frage, ob es für die echten Style Dinge hilft. Um einen anderen Style darzustellen hilft es eben nicht mal nur so einfach ein paar Werte in einer CSS Datei zu ändern. Ein anderer Style hätte hier vielleicht sogar die Notwendigkeit die Templates des kompletten Systems zu überarbeiten, oder sehe ich das falsch? Der Hintergrund dafür sind meine Überlegungen bezüglich des StyleBox Systems welches langsam zu leben anfängt, ich habe das via PHP fertig gedacht und probiert, nun hatte ic versucht das vielleicht in Smarty nachzubauen, aber da fehlt mir aktuell entweder ein wenig Hirnschmalz, oder ich hab das komplette System missverstanden.
@K00ni: Die DB Klasse für DB2 ist für mich erstmal gestorben, da gibt es aktuell zu viele Hürden die mir die DB2 SQL Funktionen auferlegen.

Ein anderer Style hätte hier vielleicht sogar die Notwendigkeit die Templates des kompletten Systems zu überarbeiten, oder sehe ich das falsch?[/quote]
Genau das sollte bei einer Trennung von semantischer Auszeichnung und Layout eben nicht passieren. Ein gutes Beispiel ist CSS Zen Gardens. Dort wird jeweils nur das Stylesheet ausgetauscht, während der (X)HTML-Code jeweils identisch ist. Dazu gehört natürlich auch, dass man (etwas) Hirnschmalz in CSS steckt.

[Powie]

Würde aber heissen das ich nur Klassen und ID\'s nutzen kann welche im Code vorkommen. Wenn ich meine das ein DIV komplett anders auszusehen hätte als andere, würde mir ja doch nichts anderes übrig bleiben als eine neue Klasse zu generieren -> imho Template anpassen.

Würde aber heissen das ich nur Klassen und ID\'s nutzen kann welche im Code vorkommen. Wenn ich meine das ein DIV komplett anders auszusehen hätte als andere, würde mir ja doch nichts anderes übrig bleiben als eine neue Klasse zu generieren -> imho Template anpassen.[/quote]
man http://www.edition-w3c.de/TR/1998/REC-CSS2-19980512/kap05.html\" rel=\"external nofollow\">Selektoren
Davon abgesehen sollte einfach jedes Element mit einer ID versehen sein, außer(!) es handelt sich um Elemente, die sich wiederholen, bsp. abwechselnd farbig gestaltete Tabellenzeilen (für was auch immer man sowas benötigen sollte). Hier sollte das Mutterelement (die Tabelle) eindeutig identifiziert sein (id) und die Reihen jeweils klassifiziert sein. Außer dieser Kombination kann man dann mit Hilfe der oben erwähnten Selektoren eine eindeutige Identifizierung ableiten.

[Powie]

ja ok... klaro... im Prinzip wäre es ja mit anderen Varianten der Templateisierung auch nicht anders.....
Von den Funktionen und dem \"Einbau\" von Smarty hab ich mittlerweile einen ganz guten Überblick. Um ein relativ einfaches Projekt damit aufzuziehen reichen die Kentnisse. Aber um zum Bsp. pSys da drauf zu heben fehlt mir aktuell komplett der Ansatz wie man das am besten angeht, hier ist ja einiges doch wesentlich komplexer als einfach nur ein bissel HTML mit Header und Footer.

ja ok... klaro... im Prinzip wäre es ja mit anderen Varianten der Templateisierung auch nicht anders.....[/quote]
Genau. Das Grundprinzip ist eben, dass man Logik von Output trennt und im Output Semantik von Design.

Aber um zum Bsp. pSys da drauf zu heben fehlt mir aktuell komplett der Ansatz wie man das am besten angeht, hier ist ja einiges doch wesentlich komplexer als einfach nur ein bissel HTML mit Header und Footer.[/quote]
Es geht. Ich habe schon komplexere Projekte (nachträglich) templatetisiert.
Hinter den http://games-workshop.biz/\" rel=\"external nofollow\">Games Workshop Händlerseiten steht z.B. eine von mir selbstgeschriebene Template-Engine (lightweightTP, Smarty konnte damals aus diversen Gründen nicht verwendet werden), die auf einem ähnlichen Umfang und ähnlichen Module wie PSys basieren. Ist im Übrigen vollständig PHP4-Objektbasiert (aus 2003/4).

[k00ni]

Aber um zum Bsp. pSys da drauf zu heben fehlt mir aktuell komplett der Ansatz wie man das am besten angeht, hier ist ja einiges doch wesentlich komplexer als einfach nur ein bissel HTML mit Header und Footer.[/quote]
Ich finde gerade den Thread nicht mehr, aber es gab hier mal vom Otti die Vorstellung eines neuen Stylesystems. Man teilt die Seite in 3 Bereiche (links, mittig, rechts) ein und kann dann differenzierte Designs erstellen. Dabei waren glaub ich die vom Statler angesprochenen Selektoren.
In diesem Zusammenhang würde ich gern noch eine zweite Idee in den Raum stellen. Ich hoffe, der Otti killt mich dafür nicht. /uploads/emoticons/icon_e_biggrin.gif.1a84f5257b36e14b36d04985314f877f.gif\" alt=\":-D\" />
 
In Friends haben wir den HTML- und PHP-Code getrennt gelagert.
 

foo.php
foo.tpl

 
 
Diese tpl-Datei enthält die Struktur, die Verweise auf die CSS-Klassen und hier und da ein wenig PHP für die Ausgabe der Daten (bspw. Schleifen oder if-Abfragen). Dies entspricht noch lange keinem Templatesystem! Aber es stellt eine Erleichterung für die bisherigen Nutzer dar. Man kann nämlich einfach updaten, ohne gleich das Design bzw. die Struktur der Seite zu zerstören.
Nun kommt der Clou. Zur Zeit sieht die Struktur ja ungefähr so aus:
 

- admin
- news
- blog
- lib
- ...

 
 
In jedem Ordner liegen wieder alle Dateien. Erstens würde ich hier zwischen Back- und Frontend trennen. Zweitens könnte man nun, statt die tpl-Dateien (siehe oben) in dem gleichen Ordner, wie die PHP-Dateien zu belassen, zentral ablegen. Meinetwegen im style-Ordner.
Da würde sich dann folgendes ergeben:
 

- news
--- admin 
------ index.php
------ edituser.php
------ ...
- ...
- style
--- foobar
------ css (1)
------ structure (1)
------ tpl (2)
---------- forum
--------------- showthread.tpl (3)
--------------- register.tpl
---------- news
--------------- ... 

 
 
Man hat nun zu jeder, ich nenne sie mal Komponente, wie News, Blog, Forum, die tpl-Dateien im tpl-Ordner im style-Ordner liegen, siehe 3. Dies wirkt vielleicht auf den ersten Blick verwirrend. Man kann aber nun selbst in den unterschiedlichen Styles, auch unterschiedliche Strukturen der Komponenten, und ich würde es sogar noch etwas weiter treiben, der Module erstellen. Die Oberflächen (.tpl) liegen ja dann in einem Unterordner in style, siehe 2.
Das bisherige Style-System würde ich beibehalten. Nur würde ich es dann aufteilen, in einen css- und einen structure-Ordner, siehe 1.
Man hat dann also zentral alle Oberflächen liegen und kann dann verschiedene Styles erstellen. Andere Strukturen, geänderte CSS-Klassen in den HTML-Elementen usw.
Die User wollen eigentlich die Struktur kaum verändern, wenn man sich die Seiten anschaut. Ein wenig im CSS herumfummeln und hier und da was verschieben, fertig. Mit dem System kommt man den Leuten entgegen, dass man sozusagen, mit einem Klick, die komplette Struktur der einzelnen Teile bzw. des kompletten pSys verändert.
Denkbar wäre dies nicht nur fürs Frontend. Auch fürs Backend wären verschiedene Styles möglich.
 
Grüße

Sinnvollerweise sollte man die Template-Files und die Library-Files außerhalb des Document Root aufbewahren.

[Powie]

Original von Statler Sinnvollerweise sollte man die Template-Files und die Library-Files außerhalb des Document Root aufbewahren.
[/quote]
Leider für die meisten Dau User nicht realisierbar, dort würde wietaus mehr hingehören noch. Bei Confixx haben die User noch ein /files Directory ausserhalb der DocRoot, wissen aber meist nichts damit anzufangen.
Die Variante vom Otti kenne ich, nicht nur vom Thema damals, auch weil wir oftmalsversucht haben genau solche Design\'s aufzubauen. Langsam kalppt das auch  /uploads/emoticons/icon_e_surprised.gif.a8707b3f35a569cb4cfe563fc72ef78d.gif\" alt=\":-o\" />/uploads/emoticons/icon_e_surprised.gif.a8707b3f35a569cb4cfe563fc72ef78d.gif\" alt=\":-o\" /> .
Ich denke um das bestmöglich zu verändern wird die komplette Ordnerstruktur noch einmal komplett verändert, somit könnte dann z.Bsp auch der Admin Bereich komplett woanders liegen. Es wird vermutlich ein Aufwasch werden mit den Language Support, allerdings bin ich mir noch nicht im klaren ob ich Smarty  beginne einzusetzen oder mir nicht doch selber was generiere. Beides hat Vorteile wie Nachteile, ..... beim Eigenbau wüsste ich wie ich manches handeln würde, bei Smarty sind mir noch Dinge suspekt wie zum Beispiel die Integration in die Panel Struktur etc.

[k00ni]

Ich habe mich gerade gefragt, was das an Zeit kostet, die gesamten Module und Komponenten auf Smarty umzustellen. Es ist ja zur Zeit schon kaum eine Entwicklung von Kleinigkeiten zu sehen. Woran also liegt das? Kein Interesse bestehendes weiterzubasteln? Neues ausprobieren? Ich mein, wo liegen den derzeit die Prioritäten im pSys bei dir, Powie?

Die Variante vom Otti kenne ich, nicht nur vom Thema damals, auch weil wir oftmalsversucht haben genau solche Design\'s aufzubauen. Langsam kalppt das auch[/quote]
Und ich fand die Variante eigentlich auch sehr geil. Das pSys will ja kein CMS sein, also warum muss es dann so fett werden? Ich stelle mir vor, dass das sehr viel Aufwand für die Erstellung und den Betrieb von Seiten in Smarty bedeutet. Nicht nur, dass man erstmal alles umstellen muss, oder geht der Parallelbetrieb? (Smarty + jetziges System) Sondern bestehende Seiten müssen ihr komplettes Design übern Haufen werfen.
Ich find Brüche gut. Wo es Sinn macht. Aber wenn es so schon kaum Neuigkeiten im System gibt, warum dann so einen riesigen Klopper anpacken?
Ich denke, man sollte beim derzeitigen Kurs bleiben. Eine saubere Trennung von PHP und HTML / CSS Code, bspw. durch das von mir oben angesprochene \"System\", was ja nicht sehr schwierig umzusetzen wäre. Der Vorteil lege darin, dass man für jede Seite, 2 Dateien hat und fertig. Möchte man etwas an einem Punkt ändern, passt man die entsprechende Datei an. Soll es global geändert werden, dann macht man es in der CSS-Datei. Und soll es etwas Extrawagantes sein, dann macht mans selber.
Meine Bedenken gehe in die Richtung, dass das pSys so ein Brocken von Code wird, den keine Sau mehr benutzen kann. Man ist nur noch auf die bereitgestellten Module angewiesen, weil es eine Qual wird, sich selbst etwas zu basteln. Bleib dem bisherigen Prinzip treu: Keep it simple and fast.
Ich lasse mich auch gerne eines besseren belehren. Ich habe mit Smarty und Co. noch nicht sehr viel gemacht, eher ein paar Tutorials gelesen. Wenn die Integration nicht sehr viel Aufwand erfordert auch gut. Nur bitte beginnt hier keine Pseudogedanken alá: \"Ja, damit kann man X, Y und Z machen und es ist allgemein viel toller.... .\" Bloß, brauchen \"wir\" das wirklich? Oder eher 2 Leute, von 200 ? Und das Ende vom Lied ist doch bisher immer, wer setzt es um?

[Powie]

Nun, ich versuch es mal zu erklären was mich letzten Endes dauz bewogen hat auf smarty zu setzen.
... es ergab sich in den letzten Wochen eine Menge Arbeit damit, einfach verschiedene Techniken zu testen um verschiedene Dinge unter der Oberfläche von pSys zu verbessern. Die wichtigen Dinge für eine weitere Verbesserung, und von vielen Usern gewünscht sind:
1. Templates -> diese sind \"einfacher\" anzupassen als php Code!!!
2. Language Support.
Letzterer war für mich bisher weniger wichtig, aber durch ein aktuelles eigenes Projekt ist es für mich ein MUSS ein Modul eben in verschiedenen Sprachen zu haben. Und da kommt es nun bei Smarty zusammen, denn es hat sich mir eine Möglichkeit geboten, beide Punkte miteinander zu vereinen, als ich beim Testen und Ausprobieren auf eine geniale Möglichkeit gestossen bin den Language Support über Smarty zu implementieren. Ein Rework der Files, egal für welche beider Sachen, wäre so oder so notwendig. So passiert beides in einem Step.
Man lernt Smarty relativ schnell, vieles erklärt sich von selbst.
Smarty ist auf dem üblichen Weg eingebunden. Ich erzeuge zusätzlich eine eigene Erweiterung der Smarty Klasse, dieser gebe ich bereits vom pSys vorgehaltene Compile und Cache Verzeichnisse mit.
Zusätzlich hänge ich ein \"Language\" Objekt an, beim Create wird der LanguageCode festgelegt ( de, en, it, ... ).
Zusätzlich registriere ich bei Smarty einen Precompiler Filter für meinen Language Parser.
Die Languagetags sind in den Smarty Templates normal hinterlegt mit Delimitern.
Wird ein Template geparsed, so wird je Sprache, ein eigenes instanzierte Compilat abgelegt. Beim ersten Compilieren oder wenn sich das Template geändert hat, werden die Language Tags gegen die Bibliothek verglichen und ersetzt. Existiert der Tag in der Bibliothek nicht, so wird er leer angelegt und kann später im Adminbackend ergänzt werden. Im Template wird er ohne Delimiter weiter ausgegeben. Somit muss aktuell kein eigentliches Language File vorbereitet werden, dies ergibt sich automatisch sobald die Tags in Templates verwendet werden.
Die compilierten Templates werden somit in übersetzter Form gespeichert, man benötigt also, wenn einmal compiliert, theoretisch die ganze Language Bibliothek garnicht mehr. Damit ergibt sich: Ressourcenaufwand = 0.
Als ich auf den Dreh gekommen das so zu machen, wollte ichs probieren, und siehe da das funktioniert! (VERDAMMT DIE SCHEISSE GEEEEEEHT!) . Ich sehe dies keinesfalls als Nachteil an, schon garnicht für die Designgeschichten.
Speziell die \"Otti\" Variante ist damit viel simpler machbar! Wobei es dafür sowieso keine Einschränkung gibt, man kann mit den bisherigen Style Files eine Menge Unsinn anstellen, auch die Ottivariante /uploads/emoticons/icon_e_smile.gif.4a0acefcb917340d2c82e5239c009e6e.gif\" alt=\":)\" />.

[Powie]

Ein Template Beispiel  /uploads/emoticons/icon_e_surprised.gif.a8707b3f35a569cb4cfe563fc72ef78d.gif\" alt=\":-o\" />/uploads/emoticons/icon_e_surprised.gif.a8707b3f35a569cb4cfe563fc72ef78d.gif\" alt=\":-o\" />/uploads/emoticons/icon_e_surprised.gif.a8707b3f35a569cb4cfe563fc72ef78d.gif\" alt=\":-o\" />
 

    ##PLvisitors## ##PLstats##
 
         ##PLyear##
         01
         02
         03
         04
         05
         06
         07
         08
         09
         10
         11
         12
         ##PLsum##
{foreach name=outer item=year from=$daten key=jid}
      {$jid}
      {foreach key=mid item=month from=$year}
         {if $month == 0 }
             0
          {elseif $mid == \"max\" }
             {$month}
          {else}
             {$month}
          {/if}
      {/foreach}
{/foreach}