WebsiteBaker Community Forum
WebsiteBaker Support (2.8.x) => 
Hilfe & Support (deutsch) => General Help & Support => Diskussion über WB (closed) => Topic started by: NorHei on January 07, 2013, 12:00:39 PM
-
Diskussionen über Template Engines und dern Sinn und Unsinn hatten wir ja schon öffter, aber jetzt hatten wir in einem anderen Thread eine doch recht fruchtbare Diskussion zu dem Thema.
Dabei bin ich selbst als hartnäckiger Kritiker an dem Punkt angelang wo ich sagen mag: "Halt , hier macht das Sinn"
https://forum.WebsiteBaker.org/index.php/topic,25276.0.html
Da die Diskussion um TEs aber nicht in einen Modulthread gehört führ ich Sie mal Hier weiter.
Kurzfassung:
Also das Problem war das Modul Members welches genauso wie das Newsmodul und viele andere die Möglichkeit bietet im Backend eingene kleine Templates für die Erzeugung der Seite anzubieten.
Zur Zeit wird mit str_replace() ein kleines Set von "Templatevariablen" angeboten die aber im prinzip sehr wenig Flexibilität Anbieten. Eine Templateengine kann das ganze natürlich wesentlich flexibler gestalten hat aber eventuell eine hohe Lernkurve die für das bedienen eines Modul backends eher nicht geeignet ist. Zudem entsteht durch das häufige aufrufen der in der view.php jede Menge Speicherbedarf und die Geschwindigkeit der Seite bricht kräftig ein.
http://web-developer-blog.com/2012/10/template-engines-im-vergleich-teil-3.html
http://www.phpcomparison.net/index.php?template%5Bphp%5D=on&template%5Braintpl%5D=on&template%5Bsmarty%5D=on&template%5Btwig%5D=on&test=assign
Jetzt stellte sich die Frage ob es eine Gute Idee wäre die TE einfach beim speichern der Seite das fertig compillierte Template speichern zu lassen und damit WB viel Arbeit zu sparen und dafür zu sorgen das alles schön schnell rennt.
Es Wurde darauf verwiesen das TWIG dies wohl beherscht allerdings enthüllt ein blick in die Doku das das was da Compilliert wurde zwar PHP ist aber das es beileibe nicht frei von Overhead ist .
The generated template for a Hello {{ name }} template reads as follows (the actual output can differ depending on the version of Twig you are using):
/* Hello {{ name }} */
class __TwigTemplate_1121b6f109fe93ebe8c6e22e3712bceb extends Twig_Template
{
protected function doDisplay(array $context, array $blocks = array())
{
// line 1
echo "Hello ";
echo twig_escape_filter($this->env, $this->getContext($context, "name"), "ndex", null, true);
}
// some more code
}
Als PHP template wäre das ein :
Hello <? echo $name ?>Und escaped wird gefälligst vorher(Escape Filfer ist nicht immer automatisch gewünscht).
Keine Frage was da schneller rennt.
(Da wundert es auch nicht das die meisten TE ohne Caching immer noch deutlich langsamer und speicherhungeriger sind als PHP)
Was ich mich jetzt frage ist , gibt es TE die wirklich simplen PHP code erzeugen kann?
Wenn man den nämlich dann speichern würde müsste das ganze doch eingendlich ohen Overhead rennen können.
-
Hallo,
Was ich mich jetzt frage ist , gibt es TE die wirklich simplen PHP code erzeugen kann?
Für kleinere Projekte habe ich in der Vergangenheit gerne die Template Engine (TE) Savant (http://phpsavant.com/docs/) benutzt. Diese verwendet PHP selbst, benötigt also keine "Lernkurve". Recht schnell und resourcenschonend ist wohl auch die TE Haanga (http://haanga.org/) (aber nie selbst benutzt).
Ich für mich unterscheide meist folgende Anwendungen:
Ist die Ausführung von PHP Code in Templates erlaubt, benutzte ich in der Vergangenheit meist PHP oder Savant (http://phpsavant.com/docs/). Ist PHP in Template nicht gewünscht, verwende ich fast immer Twig. Auch bei grösseren Projekten wirkte sich das oft nachgesagte langsames "parsen" bei TE dank dem Cachen der Seiten bisher nie wirklich aus.
Seit einiger Zeit verwende ich fast ausschliesslich Twig (bei ganz einfachen Projekten, bei denen Twig nicht bereits zur Verfügung steht, weiche ich in ganz selten Fällen auf pures PHP aus). Meine Vorliebe zu Twig hat auch damit zu tun, dass sich Twig nahe an Pythons Django TE ausrichtet (das ist aber eine andere Sache).
Denke Links zu Templateengines gibt es im Netz zuhauf, einige ausgesuchte hier:
http://fabien.potencier.org/article/34/templating-engines-in-php
http://it-republik.de/php/news/Template-Engines-vs.-PHP-058161.html
http://www.webresourcesdepot.com/19-promising-php-template-engines/
Gruss
-
Man sollte bei dem Hin-Und-Her der Performance auch eine Sache nicht außer Acht lassen:
PHP Code selbst wird in C++ "umgewandelt", dann in "Assembler", dann geht's erst zur CPU. Nicht zu sprechen von den Datenpaketen, die alle auf ca. 1000Byte verkleinert werden (OSI-Schicht). Noch gar nicht zu sprechen, von den Zig-Routern, die zwischen A und B liegen, Firewalls, etc.
Das heißt das, was ein Computer/Server/Netzwerktechnik leistet ist im Vergleich zu dem "umständlich" erscheinenden Twig-Code eher zu vernachlässigen.
-
Ich halte gar nichts von Template Engines. Nach meinem Verständis ist PHP selber die beste.
<?= $variable ?> kann ich überall einbauen, aufwändige Funktionen auslagen und das war´s.
-
Zupf mir jetzt nicht gleich den Kopf ab, wenn ich Deinen Post leicht korrigieren muss. Ich weiss, dass Du das Richtige meintest. ;-)
... PHP Code selbst wird in C++ "umgewandelt", dann in "Assembler"
...
Ersetze bitte 'Assembler' durch 'Maschinencode' dann passts wieder. ;-)
Assembler ist auch nur eine, direkt an die Maschine angepasste, 'Hochsprache', die erst mal in reinen Binärcode übersetzt werden muss. [ geschrieben wird da z.B. MOV A,B und im Programmspeicher wird nach der Übersetzung dazu nur der HexWert C4 abgelegt. (ist nur ein nur Beispiel, keine echte Anweisung)]
Das heißt das, was ein Computer/Server/Netzwerktechnik leistet ist im Vergleich zu dem "umständlich" erscheinenden Twig-Code eher zu vernachlässigen.
Ich denke, das wolltest Du auch umgekehrt sagen:
Das heißt dass der "umständlich" erscheinende Twig-Code, im Vergleich zu dem was ein Computer/Server/Netzwerktechnik zur Auslieferung einer Seite sonst noch leisten muss, eher zu vernachlässigen ist.
-
@frankwii
Die PHP short tag Varianten sind erst ab PHP 5.4 standardmässig aktiviert, vorher muss man shorttags selbst aktivieren. Meine auch mal gelesen zu haben, dass sich die shorttags in manchen Fällen mit XML templates beissen. Der Unterschied ist aber nicht wirklich dramatisch
<?= $variable ?> oder halt ohne shorttags
<php echo $variable ?>
@blackbird: Weisst Du ob Dwoo noch aktiv weiter entwickelt wird?
-
Also irgendwie hab ich das Gefühl da hat der ein oder andere den Anfangsthread und die Verlinkten Seiten ned richtig angeschaut.
Anfangsthread:
1. An einer solchen Stelle im Modulbackend kommt wan um irgendeine Form des Templating nicht herum.
2. Full PHP ist spätestens wenn man eine Seite die Groß genug ist das man mehrere Authoren hat ein absolutes Nein.
3. Selbst bei nur einem Kunden der dran bastelt ist die Wahrscheinlichkeit sehr hoch das er die Seite ausser Funktion setzt.(Welcher Kunde ist schon PHP Profi und ein fehlendes Komma oder so und wir bekommen ne hübsche Fehlermeldung und sonst nichts.)
Die Links :
Nehmen wir mal :
http://web-developer-blog.com/2012/10/template-engines-im-vergleich-teil-3.html
Der Unterschied in der Geschwindigkeit liegt im Sekundenbereich (0,6 sekunden zu 7,3 das ist Faktor 12)
Das ist extrem bemerkbar.
Der Unterschied in der Speichernutzung ist noch extremer (11kb zu 543kb das ist Faktor 49)
Was die Netzwerkebene betrifft, so ist die deutlich schneller. Ein Ping an WebsiteBaker.org dauert bei mir etwa 0,15 Sekunden für Hinn und Rückweg übers Internet, lokal auf meinem Recher dauert das sogar nur 0,000051 Sekunden. Die ganze Netzwerkebene ist halt auch in C geschrieben und nicht in einer Templatesprache die innerhalb einer anderen Interpreter (Interpiler?) Sprache rennt.
Der Übliche Billighoster hat immer noch 1000-2000 Accounts pro Server und bei PHP maximal 32 MB Memorylimit. Also ist die Leistung eigentlich drastisch eingeschränkt.
Des Weiteren hebeln viele TEs die Servereigenen Optimierungmöglichk eiten wie Opcode Cache völlig aus. Dies Möglichkeite sind meist in C geschrieben und damit um längen effektiver als ds PHP basierte Caching von PHP. (Nebenbei bemerkt ist meines Wissens nach PHP auch in C geschrieben http://de.wikipedia.org/wiki/PHP )
Weiter gehts:
Das, was WB als TE mitliefert, ist heutzutage völlig indiskutabel.
Keine Frage :lol:
Deswegen hatte ich halt mal die Überlegung angestellt ob es nicht was gibt ohne die bekannten Nachteile. (JAA die haben auch Vorteile, zum Beispiel das es an der Stelle im Members Modul gar nicht anders Realisierbar ist, denn auch str_replace() ist ne TE)
@cwsoft :
Hmmm habe ich das richtig verstanden Savant ist sozusagen templating mit Plain PHP aber eben mit Hilfsfunktionen und einer Struktur drumm herum ? Gefällt mir als alter PHP Fan.
Das kammt aber eben leider grade im Module BE eher nicht in Frage
weil volle PHP Power dort wohl wirklich nicht am rechten Platz ist.
Ziemlich praktisch fand ich die TE von Thorn in seinen PMF Modul. Da Thorn und sine Seite einfach verschwunden sind hänge ich mal die Doku als .zip an . Das Resultat waren einfache PHP Dateien die wirklich komplett ohne Overhead liefen. (und das im Server integrierte Caching nutzen konnten)
Eine deiner Links brachte mich dann hier hinn:
http://gonzalo123.com/2011/01/24/php-template-engine-comparison-part-2-versus-plain-php/
Dort wird Haanga erwähnt zumindest auf den ersten Blick macht die es offensichtlich so ähnlich wie Thorn.
http://haanga.org/
Leider ist die Lizenz ein wenig :-P
Ich sehe wirklich keinen Grund, warum man bei WB unbedingt den Weg gehen muss den alle anderen auch gehen.
-
Da ich persönlich schon genug zum Thema "Sein oder Nich-Sein" für Template Engines geschrieben habe (und auch oft wirklich ermüdende Debatten daraus resultiert sind), will ich mich nicht weiter äußern.
Die beste Begründung, die ich geben konnte, ist in diesem Post zusammengefasst:
https://forum.WebsiteBaker.org/index.php/topic,25276.msg172279.html#msg172279
Ich freue mich, dass die nun eingebaute TWIG besser ist, als das was wir bisher hatten und dass es viele Codeschreiber gibt, die diese TE für brauchbar halten.
Alles andere wird sich in der Praxis entscheiden.
Ich denke CWSoft hat mit seinen Modulen gezeigt, dass die Syntax keine besonders hohe Lernkurve für den Layouter darstellt. Und selbst wenn - es gibt hier ein Forum, wer Fragen zum Thema Gestaltung haben wird, wird fragen und wie immer antworten bekommen.
Gruß,
Stefek
-
Jep shorttags sind erst ab 5.4 standard (leider) also funktioniert das nur auf etwa der Hälfte aller Server.
Das Problem ist das Ich zum Beispiel die PHP Syntax auswendig kenne aber für die blöden TEs immer erst in die doofe Dokumentation schauen muss, es gib ja mehr als nur WB und TWIG und da sind immer wieder ettliche Kleinigkeiten anders. Das ist echt wiederwärtig.
Wer meint die Syntax einer TE ist soo viel leichter muss nen Knoten im Hirn haben. Aber ich tippe da dann ma auf Designer ohne PHP Vorkenntnisse. Die Unterschiede in der Sytax sind eher ... minimal, wer Programmieren kann versteht das eine So wie das andere. Und ja, ein Wenig einfacher ist die Syntax. Aber einen Vorteill muss ich wirklich einräumen, und zwar das sie Fehler besser verzeihen kann. (Fehlende Kommas und sowas ) Ansonste gilt : "Alles was ich schon kannn ist natürlich leicht".
Nebenbei bemerkt ging es beim Ursprungsthread um das Backend eines Modules und da kann man keinem zumuten 100 Seiten Doku zu lesen da sollte bei den Vorgefertigten Sachen auf jeden Fall keine komplexe Templatelogik drinn sein sondern nur einfache Ersetzungen. Das man auch Komplexe Sachen machen kann ist ja OK aber das sollte nicht der Standard sein sonst muss der Anwender sich nämlich doch erst durch viele Seiten Doku wälzen und das gibts bei anderen CMS schon oft genug
Du findest garantiert auch Seiten, die genau das Umgekehrte behaupten.
Ohhh, Nö ....keine gefunden, denn ->
Klar ist: Nichts ist schneller als reines PHP
:lol:
Erfahrungsgemäß ist Jede Abstaktionsebene um den Faktor 10-100 Langsamer als ihr Vorgänger bei TEs ists etwa Faktor 10 (oder 100 bei Typo ;-)) Deswegen war ich ja auf der Suche nach einer TE die dieses Problem dadurch löst das die Zeit an anderer Stelle aufgewendet wird als wenn die Siete ausgeliefert wird. Sie vielleicht eine Compiler bietet der nicht so einen Overhead erzeugt wie der von TWIG wobei der von TWIG ja schon besser ist als nichts.
-
Ohne mir den Code jetzt angeschaut zu haben, wer was Einfaches sucht, kann ja mal einen Blick in die TE von F3 (Fat Free Framework) werfen.
Schaut ned schlecht aus.
-
Das Problem ist das Ich zum Beispiel die PHP Syntax auswendig kenne aber für die blöden TEs immer erst in die doofe Dokumentation schauen muss, es gib ja mehr als nur WB und TWIG und da sind immer wieder ettliche Kleinigkeiten anders. Das ist echt wiederwärtig.
Mach Dir keinen Kopf um die Syntax.
Die Grundsyntax von TWIG ist kinderleicht.
Ich vermute mal, Du willst in Deinen Modulen nicht ALLE in TWIG vorhandenen Möglichkeiten ausschöpfen.
Es geht eben mehr mit TWIG als mit str_replace.
Schau Dir doch mal die vorhandenen fertigen Module von CWSoft an, die bereits mit TWIG laufen.
Wo ist das denn kompliziert? Weder die Layout-Schicht noch die Code-Schicht ist überwältigend.
-
@Werner:
Nein, ist so völlig korrekt. Ich wollte nur damit sagen, dass hinter den Kulissen so dermaßen viel passiert, was niemand mitbekommt. Wird ja kaum einer
mov eax, DWORD PTR [rbp-8]schreiben wollen.
-
@norhei
Savant entspricht in etwa dem was Contao als TE anbietet.
@norhei, frankwis
Meines Wissens kann man short tags (http://php.net/manual/de/ini.core.php#ini.short-open-tag) über PHP aktivieren, ob das immer geht, weiss ich nicht. Bleibt dann noch die XML Template Geschichte.
Bei den Anynews-Templates (https://github.com/cwsoft/wb-cwsoft-anynews/tree/master/cwsoft-anynews/templates) hält sich die Lernkurve in Grenzen und viele Wünsche konnten einfach über ein angepasstes Template realisiert werden, statt wie zuvor über den Anynews PHP Code. Da ich Members nicht nutze, weiss ich nicht ob sich eine TE für Members wie bei Anynews lohnt.
Mir ist ist Weiterentwicklung, grosse Userbasis, vernünftige Doku und Standardisierung einer TE lieber, als wenn nun jedes Modul seine eigene Templateengine mitbringt. Twig wird mit WB ausgeliefert, warum also nicht verwenden.
-
Das ist ein Punkt der mir einfach aufgrund der Vielzahl der TEs sehr auf den Geist geht, oder weist Du auswendig die Sytax von Smarty, Twig, PHPLib, Quickskin und Typoscript? Mit dem Gesülze musste ich mich bis jetzt rumplagen.
Man muss halt immer wieder nachschauen :-(
-
@cwsoft
Shorttags ist ne Compiler Option, kann aktiviert werden wenn mit rein compliliert, sonst ned.
Wer wie bei Anynews mit nem Editor im Dateisystem unterwegs ist kann ganz andere Sachen als ein Anwender im BE.
Ich habe aber auch nur gesagt das das Standard Template nicht komplex sein soll, nicht das man die Möglichkeiten abschalten soll.
-
Frage: Schluckt Dwoo auch Strings aus ner Datenbank ?
-
Nö. Ich such mir eine aus, die mir gefällt, und die nehm ich dann. Deren Syntax weiß ich dann und fertig. Wobei Du ja gesehen hast, daß ich tatsächlich die Varianten aller TEs kenne, die ich bisher benutzt habe, selbst die von Perl, was schon Jahre her ist. Für den Rest gibt es die Doku.
...
Aufgeregt hat mich das noch nie, obwohl ich schon mit vielen unterschiedlichen TEs gearbeitet habe. daher kann ich das jetzt auch nicht nachvollziehen.
Richtig, sehe ich auch so.
Man weiß es dann eben - und wenn nicht, schaut man nach. Es ist nun wirklich nicht so kompliziert.
Vorteil mit TWIG in WB kann dann aber sein, dass wir dann zum ersten Mal eine wirklich brauchbare TE global verwenden können, statt viele unterschiedliche "Mitbringsel". Bin mir sicher, dass Dwoo von Ralf nie benutzt worden wäre, wenn TWIG schon vorhanden gewesen wäre - es war der Mangel an einer logischen TE, der uns immer wieder auf die Suche getrieben hat.
-
Frage: Schluckt Dwoo auch Strings aus ner Datenbank ?
Häh?
@BB
Gemeint ist wohl das hier:
https://forum.WebsiteBaker.org/index.php/topic,25276.msg172328.html#msg172328
-
Wer wie bei Anynews mit nem Editor im Dateisystem unterwegs ist kann ganz andere Sachen als ein Anwender im BE.
Anynews hat keinen Editor im Backend. Die Anynews Templates könnte man auch einfach als ein Forminputfeld ähnlich den Schleifen im News Modul über das Backend realisieren und statt als Datei halt in der Datenbank des Moduls speichern. Ich habe das halt über dateien gelöst, muss man aber nicht.
-
Wer wie bei Anynews mit nem Editor im Dateisystem unterwegs ist kann ganz andere Sachen als ein Anwender im BE.
Anynews hat keinen Editor im Backend. Die Anynews Templates könnte man auch einfach als ein Forminputfeld ähnlich den Schleifen im News Modul über das Backend realisieren und statt als Datei halt in der Datenbank des Moduls speichern. Ich habe das halt über dateien gelöst, muss man aber nicht.
Interessante Debatte....das wäre die nächste Frage gewesen.
Arbeite viel mit Dwoo und Ralfs Modulen.....aber wie schon erwähnt ist TWIG das gleiche in grün und wenn es eine Standard in WB werden sollte soweit aktuell und technisch auf Stand auch nur zu begrüßen...hier sind "detail pro/contra" fragen sowieso unnütz.
Meine Frage wäre gewesen - kann man das mit den TWIG Templates genauso (oder besser) gestalten wie mit den Settingsschleifen?
Das ist das einzige was mir in den Admintools der phpmanufaktur machmal fehlt - da ich nicht immer Zuhause meine IDE mit FTP Zugang und zwei Bildschirmen laufen habe.
Meinetwegen ein wenig versteckt oder im optimalfall per globaler Berechtigung gesperrt/frei ein Button in jedem Modul [Templates] und dann eine Liste/Formular für deren direkte Bearbeitung....
Im wesentlichen sind z.B. bei den Dwoo Modulen die Templates die früheren Settings nur übernehmen diese noch die Darstellungslogik.. .da wo ich z.B. in Members oder Topics mit Droplets "provisorisch" 2-3 Abfragen implementiert hatte.
(Wenn Wert=1 oder ' ' dann mach dies)
Um mehr geht es doch hier nicht. Die Frage ist wie man TE _einfach_ zur Verfügung stellt und _einfach_ in ein grundsätzlich _einfaches_ CMS einbaut. So dass man nicht Ostereiersuchen gehen muss (Wo waren jetzt hier bei diesem Addon die Templates, oder hmm da muss ich erst die Doku lesen damit ich den Link anzeigen lassen kann wenn in diesem Feld eine 1 steht!!!)
Gruß mr-fan
-
Arbeite viel mit Dwoo und Ralfs Modulen.....aber wie schon erwähnt ist TWIG das gleiche in grün und wenn es eine Standard in WB werden sollte soweit aktuell und technisch auf Stand auch nur zu begrüßen...hier sind "detail pro/contra" fragen sowieso unnütz.
Richtig. Das gleiche in grün.
Die Syntax unterscheidet sich auch kaum. Oder anders ausgedrückt: wer das eine kann, dem fehlt nichts, um nicht auch das andere zu verstehen.
Meine Frage wäre gewesen - kann man das mit den TWIG Templates genauso (oder besser) gestalten wie mit den Settingsschleifen?
Das ist das einzige was mir in den Admintools der phpmanufaktur machmal fehlt - da ich nicht immer Zuhause meine IDE mit FTP Zugang und zwei Bildschirmen laufen habe.
Meinetwegen ein wenig versteckt oder im optimalfall per globaler Berechtigung gesperrt/frei ein Button in jedem Modul [Templates] und dann eine Liste/Formular für deren direkte Bearbeitung....
Theoretisch ja.
Du kannst die Layout-Strings einfach in die Datenbank schreiben, anstatt der jetzigen (z.B. im NEWS) str_replace Strings.
Oder Du kannst sogar das so machen, dass die Layout-Felder (die Textareas) mit Strings aus Dateien befüllt werden.
Also im Klar-Text: man muss sich nicht unbedingt der DB bedienen, man kann auch aus den Settings heraus in Files schreiben und aus Files lesen. Wie einem bequemer.
(Da die fertigen Templates gecached werden, macht es kaum einen Performance-Unterschied, d.h. theoretisch.)
Gruß,
Stefek
-
Die Anynews Templates könnte man auch einfach als ein Forminputfeld ähnlich den Schleifen im News Modul über das Backend realisieren und statt als Datei halt in der Datenbank des Moduls speichern. Ich habe das halt über dateien gelöst, muss man aber nicht.
Man könnte tatsächlich jedes Feld (HEAD, LOOP, FOOT) und so weiter einzeln zerbrüseln, sodass man wieder für all das ein einzelnes Layout-Feld unter Einstellungen des Modules hat (ich gehe jetzt von NEWS aus), doch ich denke (finde), dass wenn man schon mit einer logischen TE arbeitet, kann man auch getrost alles in einer Datei/String inkl. Loop etc machen (so wie bei AnyNews).
Dann hätte man nur noch eine Datei/String für das NEWS und eine für den NEWS-OVERVIEW.
Na, eine noch für Comments und eine für das Comments-Form. (Ausgehend vom Newsmodul.)
Das Zerbrüseln der Strings in (HEAD, LOOP, FOOT) etc. halte ich im Fall von TE überflüßig.
Wie sehen es die anderen?
-
@mr-fan
Dafür bietet sich template_from_string (http://twig.sensiolabs.org/doc/functions/template_from_string.html) an, was mit Twig 1.11.0 eingeführt wurde.
Die aktuelle WB Twig Version im SVN ist schon etwas älter 1.7.0 und sollte VOR dem Release von WB 2.8.4 noch aktualisiert werden (aktuell ist v1.11.1). Ist halt der Vor- bzw. Nachteil von noch aktiv weiterentwickelten 3rd Party Packeten :wink:
P.S.: Auch jQuery (1.8.2 --> 1.8.3) und jQueryUI (1.9.2 --> 1.9.3) sollten vor WB 2.8.4 noch aktualisiert werden (wie ggf. weitere 3rd Party Packete)
-
Das Zerbrüseln der Strings in (HEAD, LOOP, FOOT) etc. halte ich im Fall von TE überflüßig.
Wie sehen es die anderen?
Naja mann kann das in Modulen wo es ansich logisch ist schon für die Eingabe machen und dann in ein Template gießen....das wäre halt einfach.
Die Settingsfelder waren grundsätzlich schon gut durchdacht und diese konnte man bis auf Abfragen und ein paar andere Dinge schon sehr sehr gut anpassen!
Bei einem Dwoo Addon von Ralf gibt es an sich eine andere Logik in der das genau so abgebildet ist.
Es gibt z.b. ein post.view.tpl Template das unter bestimmten Umständen auf das post.detail.tpl zugreift und ebenso auf das post.teaser.tpl - also Detail oder Übersichtanzeige wird gleich im Template bestimmt. Die Templates/Schleifen sind getrennt und nicht in einem. Wenn dieser Parameter gesetzt ist zeige mir dieses Template.
(Sehr spannend wird das ganze z.B. in KitIdea - mit eigenem Berechtigungssystem, Übersichten, Detailansichten, Gruppenaufteilung, Frontendeingabe, integriertem Login alles mit dem Admintool Templatesystem hier die Übersicht zu behalten ist schwer...)
Das ist ansich komplex - die ganze Logik ein ein einziges Template zu packen ein wenig weniger und bei z.B. Anynews geht das soweit auf Github überflogen recht schön.
Aber was ist mit komplexeren Modulen wie z.B. Topics oder auch Members mit z.B. Übersicht und Detailanzeigen?
Alles zerteilt in Files ist komplex - alles in ein Template vielleicht auch.
Die zumindest für die Eingabe/Änderung im Backend nötige Aufteilung in (nenne es mal dausprachlich) "Ausgabebereiche" ist hier eine Überlegung wert.
Pro Template eine Datei spricht wiederum für eine einfache Möglichkeit Presets zu installieren bzw. zu verweden.
Template Datei hochladen -> Auswahlliste für die Anzeige mit Hilfe des jeweiligen Templates...fertig ist ein einfaches Presetsystem für ein Seitenmodul...
Aber ihr werdet da schon was passendes finden.
Wollte nur meine Erfahrung mit Dwoo und komplexen(=vielen Templates) hier einbringen.
Frage für weiteres von Profis:
a) ist es möglich mit einem Templatefile zu arbeiten? z.B. Addons Unterordner /presets/meine-frontend-ausgabe.tpl
b) dabei aber im Backend die Settingsbereich zu trennen in "einfache" "dem Modul angepasste" "logische" Abschnitte für die Bearbeitung/Veränderung zu Unterteilen?
c) ein sehr einfaches Presetsystem für TWIG Templates bereitzustellen das verwedet werden kann....ala Listenauswahl mit Anzeige und Auswahl aller Templates in /presets/ - ist das möglich?
Eine Templateengine scheitert doch meist an zwei Punkten:
1. Kann man als Designer (bei WB auch als DAU!!) schnell und einfach ändern?
2. Kann man die Optik schnell und einfach austauschen?
Und je mehr Logik vom Modul ins Template/im schlechteren Fall viele Untertemplates wandert umso schlechter schneiden bei Punkte ab!
gruß mr-fan
-
Das Zerbrüseln der Strings in (HEAD, LOOP, FOOT) etc. halte ich im Fall von TE überflüßig.
Wie sehen es die anderen?
Naja mann kann das in Modulen wo es ansich logisch ist schon für die Eingabe machen und dann in ein Template gießen....das wäre halt einfach.
Die Settingsfelder waren grundsätzlich schon gut durchdacht und diese konnte man bis auf Abfragen und ein paar andere Dinge schon sehr sehr gut anpassen!
Nun, dass die Setting-Felder aufgebrüselt sind in die verschiedenen Bereiche wie (head, loop, foot) liegt hauptsächlich daran, dass man mit str_replace() keine andere Möglichkeit gehabt hätte (man kann damit nämlich werder eine while-Schleife noch sonst etwas "logisches" machen; daher wurde das in getrennten Feldern gemacht).
Das ist ansich komplex - die ganze Logik ein ein einziges Template zu packen ein wenig weniger und bei z.B. Anynews geht das soweit auf Github überflogen recht schön.
Aber was ist mit komplexeren Modulen wie z.B. Topics oder auch Members mit z.B. Übersicht und Detailanzeigen?
Alles zerteilt in Files ist komplex - alles in ein Template vielleicht auch.
Bei Members an sich ist es nicht viel komplexer als das AnyNews.
Ein Loop eben.
Pro Template eine Datei spricht wiederum für eine einfache Möglichkeit Presets zu installieren bzw. zu verweden.
Template Datei hochladen -> Auswahlliste für die Anzeige mit Hilfe des jeweiligen Templates...fertig ist ein einfaches Presetsystem für ein Seitenmodul...
Ja. Ich denke jedoch nicht, dass etwas dieser Art in naher Zukunft vom Core gehandhabt wird.
Man könnte aber in dieser Richtung auf jeden Fall was machen, ich habe ein Konzept, doch wenig Zeit, es umzusetzen:
https://forum.WebsiteBaker.org/index.php/topic,25276.msg172173.html#msg172173
Gruß,
Stefek
-
Eigentlich ist die Wahl des Systems ganz einfach, wenn man mal das Ganze betrachtet und nicht immer nur jeweils einzelne Teilbereiche.
Was muss ein Designer für die hier diskutierten Methoden können ?
Anzeige und einfache Logig per TE(Twig) => beherrschen der Grundsynatx von Twig
Ein Teil der Anzeigelogik im PHP-Code => beherrschen und verstehen des PHP-Codes
Zusätzliche Presets => beherrschen des Presets-Systemes
Was muss ein Designer nach unserer geplanten Komplettmethode können?
Vollständige Trennung von Programmlogik und Anzeigeschicht => für den Anfang die Beherrschung etwas erweiterter Twig-Grundsyntax... fertig
Ich denke, die Wahl fällt da nicht besonders schwer. ;-)
Man muss sich nur eben mal aufrappeln und bereit sein, neue -teilweise noch- unbekannte Wege zu gehen.
-
@mr-fan:
Aber was ist mit komplexeren Modulen wie z.B. Topics oder auch Members mit z.B. Übersicht und Detailanzeigen?
Auch komplexere (sprich mehrere Templatedateien) sind beherrschbar. Hier schafft man halt Ordnung und Klarheit durch eine aussagekräftige Benennung des Templates wie z.B. hier (https://github.com/cwsoft/wb-cwsoft-addon-file-editor/tree/master/cwsoft-addon-file-editor/templates). Haben Templates einen vernünftigen Namen, findet man sich recht einfach zurecht.
Es hilft auch, wenn logische Blöcke die öfters verwendet werden in einer Datei ausgelagert werden und dann einfach in einem anderen Template wieder eingebunden werden (DRY). Auch Template "Vererbung" und "Includes" sind kein Hexenwerk und helfen meist das Chaos zu minimieren, wie z.B. hier (https://github.com/cwsoft/wb-cwsoft-postits/blob/master/cwsoft-postits/templates) (frontend, backend, count_characters) geschehen.
Konstrukte wie {% include 'count_characters.ht t' %} überlese ich dann halt, wenn mich dieser Teil nicht interessiert und konzentriere mich auf das was zählt.
Denke wenn sich erstmal ein "Standard" etabliert hat, sind viele dieser "Diskussionen" obsolet.
-
@DarkViper
Zusätzliche Presets => beherrschen des Presets-Systemes
Könntest Du bitte kurz anreißen, was Du mit Preset-System meinst und wie es ungefähr aussehen würde?
Ich habe das starke Gefühl, dass sowohl Mr-Fan, als auch ich, mit Presets etwas anderes meinen, als Du.
Gruß,
Stefek
-
Was muss ein Designer nach unserer geplanten Komplettmethode können?
Vollständige Trennung von Programmlogik und Anzeigeschicht => für den Anfang die Beherrschung etwas erweiterter Twig-Grundsyntax... fertig
Ich denke, die Wahl fällt da nicht besonders schwer. ;-)
Man muss sich nur eben mal aufrappeln und bereit sein, neue -teilweise noch- unbekannte Wege zu gehen.
Fallen da die von cw-soft angepassten Module rein...dann hätte man ja schon eine Art Beispiel das bei Bedarf auf andere Module angewendet werden kann?
Denke solch ein großer Schritt hängt immer davon ab, inwiefern ein einfacher Modulentwickler weis das es in die richtige Richtung geht.
@Stefek: Hier wäre eine neue Methode, eigene Presetverwaltung, oder sonstige extras wohl nicht angebracht sondern schlicht auf den Punkt gebracht wie man TWIG nutzen könnte Module und Templates aufzuzbauen.
Sicher sind die Module von cw-soft eine Referenz auf Github, aber hierraus kann man ja (warum nicht in dieser Disskusion) sofort Grundsätze ausarbeiten wie TWIG (als gemeinsamer von WB unterstützter Nenner) für Modulautoren "am einfachsten" Anzuwenden ist.
Also schlicht wie käme man in einem Standardseiten Modul ala Memebers, News sonstwas auf eine einfache Umstellung auf Twig.
Das wäre ein Nutzen, Mehrwert der über die reine Disskusion hinausgeht. Und mehr bringen würde als wenn zwei Leute ein altes Modul aufbohren.
Jetzt nicht mit Modulguidelines anfangen....ich denke Werner wird sofort korrigieren wenn etwas so nicht ginge.
Twig ist gut - soweit konsens - Sollte eingesetzt werden - ebenso.
Einzig konstruktiv wäre jetzt das wie zu klären - und dann ist das fruchtbar und nutzbar für alle die daran Interesse haben sowie ich.
@cw-soft: Wie bist du die Umstellung deiner Module angegangen - was wäre hier die beste vorgehensweise?
@DarkViper
Zusätzliche Presets => beherrschen des Presets-Systemes
Könntest Du bitte kurz anreißen, was Du mit Preset-System meinst und wie es ungefähr aussehen würde?
Ich habe das starke Gefühl, dass sowohl Mr-Fan, als auch ich, mit Presets etwas anderes meinen, als Du.
Gruß,
Stefek
Denke er meint - keine Presets verwenden - nur Templatefiles sonst nichts?
(Wäre auch in Ordnung so geht das bei Ralfs Admintools auch reine Templatedateien im Ordner per Parameter bestimmt man unterschiedliche Presets.)
Bitte nicht für mich mitmeinen - könnte schon selber fragen...;)
@Werner - hier wäre grundsätzlich interessant wie du die Frage nach unterschiedlichen Templates in unterschiedlichen Seiten/Abschnitten angehen würdest? Also meinetwegen Members 3 mal mit unterschiedlichen Templates in Verwendung?
-
Bitte nicht für mich mitmeinen - könnte schon selber fragen... :wink:
Nun ja, ich gehe davon aus, dass Du bezogen auf Presets sowas meinst, wie bisher in z.B. Members zu finden ist, was also solls.
@Stefek: Hier wäre eine neue Methode, eigene Presetverwaltung, oder sonstige extras wohl nicht angebracht sondern schlicht auf den Punkt gebracht wie man TWIG nutzen könnte Module und Templates aufzuzbauen.
Das sind grundsätzlich 2 verschiedene Bereiche.
Ein Modul durch die TE zu ziehen ist nicht sonderlich schwer. Da wird es ebenfalls mehrere Herangehensweisen, abhängig vom Entwickler geben. Selbst wenn es eine "Vorgabe" gäbe, müßte man sich nicht zwangsläufig an eine solche zu 100% klammern. (Und bevor eine Art Guideline dafür kommt, werden Moduleentwickler sowieso auf ihre eigene Art mit der Twig arbeiten - falls sie sie überhaupt aufgreifen; viele werden es nicht tun).
Bei den Presets widerum ist es eine andere Sache.
Ich für mich denke da eher an "Plugins", die mehr als nur das Template und die Settings beinhalten.
(Ich denke aber nicht, dass auf so etwas hingearbeitet wird von den DEVs.)
Daher die Frage an @DarkViper, was er damit (=>presets) meint.
Gruß,
Stefek
-
@cw-soft: Wie bist du die Umstellung deiner Module angegangen
Na einfach Schritt für Schritt (sprich Datei für Datei) für alle Module: Postits (https://github.com/cwsoft/wb-cwsoft-postits/commit/bc8059708cef66f04dae172c3196a21620423f87), Anynews (https://github.com/cwsoft/wb-cwsoft-anynews/commit/6a3d3ccf4b9758059e2f2d7fe1c496ef086ca777), AFE (https://github.com/cwsoft/wb-cwsoft-addon-file-editor/commit/a436b612b1a918c726cb64bcd0363beec9ac0cf6) :-)
-
Jeder der Hier diskutierenden hat ein gewisses Maß an Programmiererfahrun g, Erfahrung mit HTML,CSS und meist auch verschiedenen TEs. Kein Wunder das da alles kein Problem ist.
Jetzt versucht euch mal in jemanden hineinzu versetzen der grade mal rudimentäre HTML Kenntnisse ala Selfhtml hat, Programmierung 0%, sprich ein Einsteiger. Aus eigener Erfahrung weiß ich das diese Leute mehr als glücklich sind wenn sie sich weder mit Verzweigungen noch mit includes oder Sowas rumschlagen müssen. Die freuen sich drüber wenn das HTML schön in HEAD LOOP und FOOTER zergliedert ist in Verbindung mit ner netten Infobox was die Grundsätzlichen Ersetzungen so Bieten... ENDE
Technisch sollte es doch gar kein Problem darstellen die 3 Boxen aus der DB zu fischenn aneinander zu hängen , noch das Loop Kommando einzufügen und dann durch die TE zu jagen.
Theoretisch würde das sogar bedeuten, das ein Profi einfach alles in den Head packen kann weil der leere Loop einfach nichts macht und der Einsteiger hätte strukturen die das verstehen drastisch vereinfachen.
Ich denk da So an meine ersten Erfahrungen mit einigen anderen CMS. Mann installiert das Script und scheitert im ersten Anlauf schon an dem erstellen der ersten Testseite scheitert. Was hab ich getan, ganz einfach das Dingen weggeworfen. Ich wollte Webseiten erstellen nicht Doku lesen, dannn hab ich WB installiert und ohne einmal in die Anleitung zu schauen eine Seite erstellt. Mit 10 minuten in die Doku schauen ein Template gebaut. Und nach ner halben Stunde lesen ein Modul gebaut und direkt noch eine Core Modifikation Nachgeschoben... einfach GEIL.
Irgendwie fällt mir da der Spruch einen CMS Jüngers von einem anderen CMS ein:
Hmmm jaaaa, das ist nicht intuitiv aber Du musst ja nur das hier im Wiki lesen und dann das hier in der Doku und vieleicht noch hier die Tutorials machen, dann ist alles gaaaanz einfach.
Und wenn ich denke wie sich ein Einsteiger fühlt der das erste mal in ein Template mit Loops, Verzweigungen und
Includes anschaut dann ist das bestimmt schlimmer als meine ersten Erfahrungen mit C64 Basic. Zumal ich das Damals aktiv lernen wollte.
Es ist schön alles machen zu können, ohne Doku. Warum ist Apple so erfolgreich? Weil es so intuitiv ist, man brauch nicht lesen sondern kann machen. Und obendrein kann man mit so einem MAC auch noch alles tun was man mit einem vollwertigen UNIX Server anstellen kann, weils ein FreeBSD ist (Gut, erst wenn man ein paar Limits entfernt hat. :lol:) So sollte es werden.
-
@Norhei
Naja für die meisten Sachen dürfte ne einfache Platzhalterersetzun g reichen, sprich {{ PLATZHALTER }}, das versteht jeder. Darüber hinaus noch IF, ELSE Konstrukte und der LOOP. Alles andere (z.B. Includes, Vererbung, Funktionen ...) sind Goodies die man nutzen kann, aber nicht muss. Ich denke in 90% der Fälle wird ein Template nicht komplexer als dieses hier (https://github.com/cwsoft/wb-cwsoft-anynews/blob/master/cwsoft-anynews/templates/display_mode_1.htt) werden. Die wichtigsten Twig Sprachkonstrukte kann man auch auf den Hilfeseiten mit Beispielen zeigen (https://github.com/cwsoft/wb-cwsoft-anynews#anynews-templates).
Bei WB Templates muss man auch ein paar Sachen lernen. Zum Beispiel wie man register frontend nutzt, loginboxen anzeigt, oder viel schwieriger sein Menü mit show_menu2 und CSS nach eigenem Gusto anpasst.
Ist aber wie alles im Leben eine Frage des Geschmackes.
-
jep showmenu() könnte was zum vereinfachen gebrauchen
-
Kleiner Exkurs zu Beginn:
Eine meiner interessantesten und lehrreichsten Erfahrungen mit Programmierung war das Leiten von Programmierern im Rahmen eines Projekt-Workshops. Ziel war es, in drei Tagen ein CMS zu programmieren. Wie war egal.
Wie soll man nun 10 Leute gleichzeitig arbeiten lassen?
Geht nicht, also ein Design Pattern genommen. Ich habe dafür ein Faible, diesmal nicht MVC, sondern das - wie ich finde für solche Fälle beste - Entity-Control-Boundary.
2 Leute haben Datenbankzugriffe (Entity) gemacht, 5 Leute die eigentliche Programmierlogik (Control) und 3 Leute mit Twig nur HTML / CSS / jQuery / "Twig-Code" (Boundary).
Das Ende vom Lied war, dass das Projekt zwar aus den Fugen geraten ist, am Ende aber sehr sauberer, nachvollziehbarer Code vorhanden war, beliebig erweiterbar. Echo wurde gänzlich verbannt, SQL gab es nur in einer einzigen gekapselten Klasse.
Und: Die 3 Leute vom Design mit Twig haben keinen einzigen Fetzen PHP gesehen - wozu auch.
Sicher ist das eine Traumvorstellung für WB (jedenfalls für mich), und wir können nunmal WB nicht mal eben umschreiben. Es soll lediglich zeigen, dass eine TemplateEngine extrem sinnvoll ist, wenn sie von A-Z durchdacht und in das Projekt integriert ist.
Ich finde es aus dem heutigen Zeitpunkt von WB und seiner Twig-Unterstützung eher schwer, sich das richtig vorzustellen. Zugegeben, ich kenne die Twig-Unterstützung von WB nicht im Detail.
Doch - damit es nicht ganz so trocken aussieht - ein Real-Beispiel für obiges "CMS" (zugegeben, die Bezeichnung ist falsch).
Es gibt eine wrapper.htt, leicht gekürzt:
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>
{{ page.head_titel }}
</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<link rel="stylesheet" type="text/css" href="css/style.css" />
</head>
<body>
<div id="site">
<div id="top">
<div id="logo">
{{ page.titel }}
</div>{% include 'top_nav.htt' %}
</div>
<div id="content">
<div id="left">
{% block content %} {% endblock %}
</div>
<div id="right">
{% include 'sub_nav.htt' %}
</div>
</div>
</div>
<div id="bg_footer">
</div>
</body>
</html>
Sie ist die Basis. Eben der Wrapper, der immer gilt. Die "Quasi - index.php" also.
Die top_nav.htt exemplarisch stellt die Navigation in einem DropDown dar:
<div id="navi">
<div id="navimain">
<ul id="header_menu" class="menu">
{% for t_nav in topnav %}
<li>
<a href="{{ t_nav.Url }}" class="{{ t_nav.Current }} navlev1">{{ t_nav.Title }}</a>
</li>
{% endfor %}
</ul>
</div>
</div>
Und last but not least eine richtig dargestellte Seite:
{% extends "wrapper.htt" %}
{% block content %}
<h1>
Servus!
</h1>
<p>
Bitte wählen Sie in der Navigation oben aus, was Sie tun möchten.
</p>
{% endblock content %}
So, det war's! Kein PHP, nada.
Sicher kann man sagen: "Warum nicht gleich PHP?".
Dann muss ich wirklich mal fragen: Was soll der Designer von heute alles können?
CSS und HTML wird hier immer als gegeben hingestellt, jQuery sowieso.
Doch alleine schon CSS ist für die meisten eine große Hürde - die Abstraktion in Zahlen ist sicher schwerer als man denkt.
Und zu dieser "künstlerischen Abstraktion" kommt noch die Programmierung dazu.
Sicher - wer sich die Mühe gemacht hat, PHP zu lernen wird blöd sein, wenn er es nicht mehr einsetzt. Oder Java, oder C#, oder JavaScript - ja, unterschätzt nicht JavaScript / ECMAScript, das wird in Umgebungen zu Zwecken eingesetzt, die man sich hier lieber nicht vorstellt. Und die Komplexität dazu auch nicht. jQuery ist auch nichts anders.
Und das ist noch lange nicht alles - für PHP und andere serverseitigen Geschichten kommt auch noch Sicherheit, Performance, Kompatibilitäten usw. ins Spiel.
Und es mag ein Klischee sein - aber ich kenne so gut wie keinen sehr guten Designer, der auch sehr gut programmieren kann. Andersrum übrigens auch nicht.
Aus oben genannten Gründen:
- Einfachheit
- Arbeitsteilung
- Leichte Dokumentierbarkeit
- Abgrenzung
finde ich eine sauber in WB integrierte Twig-Engine (meinetwegen auch eine andere, aber jetzt haben wir eine, jetzt lasst die doch mal bitte auch sein, zufriedenstellen kann man NIEMALS jeden), mit der ich auch alles ansprechen kann - vom Seitentitel über die Blöcke bis hin zu den Menüs - deutlich besser und flexibler als reines PHP.
Abschließend noch ein Wort zu Apple: Apple mag für die User ja recht angenehm sein - sie sind fast so erfolgreich wie Google mit ihrem Betriebssystem damit. Trotzdem hat Apple für die Millionen von Apps eine eigene (!!!!) Programmiersprache namens Objective-C 2.0 entwickelt (gut, zwischenzeitlich war der Vorgänger bei BSD, aber... das ist ja bekannt). Und das Faß Microsoft will ich gar nicht erst aufmachen.
Noch Fragen?
-
Meine Frage wäre gewesen - kann man das mit den TWIG Templates genauso (oder besser) gestalten wie mit den Settingsschleifen?
Als Programmierer bietet dir Twig 4 Möglichkeiten wie du eine Template verwenden kannst. Wobei - ich vermute - dass davon höchstens 2 Varianten oft genutzt werden:
Twig_Loader_Filesystem (http://twig.sensiolabs.org/doc/api.html#twig-loader-filesystem) - ist die Variante was wir von jeder TE kennen - Datei öffnen, sachen reinschreiben - ausgeben :)
<?PHP
$templateDir = '/path/to/templates';
$loader = new Twig_Loader_Filesystem($templateDir);
$twig = new Twig_Environment($loader);
echo $twig->render('index.html', array('name' => 'Fabien'));
?>
Natürlich kann man das auch erweitern:
<?PHP
$templateDir1 = '/path/to/templates';
$templateDir2 = '/path/to/templates2';
$loader = new Twig_Loader_Filesystem(array($templateDir1, $templateDir2));
$twig = new Twig_Environment($loader);
echo $twig->render('index.html', array('name' => 'Fabien'));
?>
Twig_Loader_String() (http://twig.sensiolabs.org/doc/api.html#twig-loader-string) - hier wird die zweite Variante verwendet - ein Template anhand eines Strings verwenden:
<?PHP
$loader = new Twig_Loader_String();
$twig = new Twig_Environment($loader);
echo $twig->render('Hello {{ name }}!', array('name' => 'Fabien'));
?>
Damit kann man auch die in WB oft gesehenen "Datenbank Templates" verwenden.
Wobei man etwas bedenken muss:
several tags, like extends or include do not make sense to use as the reference to the template is the template source code itself.
Aber in Zeiten wo es Tools wie den AFE oder andre Module gibt, sehe ich da kein Problem Template- Dateien zu verwenden
Sicher kann man sagen: "Warum nicht gleich PHP?".
Deine Gründe sind vollkommen richtig, aber es kann auch noch andere Gründe haben:
- Man arbeitet mit mehreren Menschen an einem Projekt (wie es eine Firma ja öfters macht), nun will der Grafiker aber wieder bei gewissen Situationen andere Elemente haben etc. - bevor ich nun jemand meinen PHP-Code umschreiben lass, ist es mir lieber er hat eine vom PHP - Code unabhängige Möglichkeit das ganze zu machen.
Davon abgesehen:
Twig hat noch weitere nette dinge, die einen das Arbeitsleben vereinfachen können - wie z.B. Macros (http://twig.sensiolabs.org/doc/tags/macro.html)
Man erstellt sich eine Datei mit folgendne Code:
{% macro input(name, value, type, size) %}
<input type="{{ type|default('text') }}" name="{{ name }}" value="{{ value|e }}" size="{{ size|default(20) }}" />
{% endmacro %}
speichert dies als forms.html (ob nun .htt, .twig oder what ever - macht in dem Beispiel keinen Unterschied ;) )
{% import "forms.html" as forms %}Diesen kleinen Code in das gewünschte Template einbauen, schon hab ich ein nettes feature:
<p>{{ forms.input('username') }}</p>
<p>{{ forms.input('password', null, 'password') }}</p>
So kann ich mir schnell und einfach input felder erstellen.
Natürlich überlasse ich jeden selbst, welche Funktionen (http://twig.sensiolabs.org/documentation) / Features er als hilfreich bezeichnet :)
-
@Badknight
Aber in Zeiten wo es Tools wie den AFE oder andre Module gibt, sehe ich da kein Problem Template- Dateien zu verwenden
Außer, dass im Falle von Section-Modulen und Layouts fürs Frontend, kann es oft vorkommen, dass Du für jede Section des gleichen Modules ein anderes Template brauchst.
Dann wird die Arbeit mit AFE schon schwieriger und es würde sich in den Fällen empfehlen, entweder tatsächlich die DB vollzustopfen, oder eine Funktion zu haben, die in den Module-Settings die Layout-Files anzeigt und speichern läßt.
Gruß,
Stefek
-
@Badknight
Aber in Zeiten wo es Tools wie den AFE oder andre Module gibt, sehe ich da kein Problem Template- Dateien zu verwenden
Außer, dass im Falle von Section-Modulen und Layouts fürs Frontend, kann es oft vorkommen, dass Du für jede Section des gleichen Modules ein anderes Template brauchst.
Dann wird die Arbeit mit AFE schon schwieriger und es würde sich in den Fällen empfehlen, entweder tatsächlich die DB vollzustopfen, oder eine Funktion zu haben, die in den Module-Settings die Layout-Files anzeigt und speichern läßt.
Gruß,
Stefek
Da hast du schon recht, man muss sich immer ansehen um welches Modul es sich handelt.
Bei Gefühlte 80% der Modulen reicht es eine normale Template datei zu verwenden, da es keine Sonderwünsche vorhanden sind :)
-
Ja.
Stimmt.
Eine Download-Gallery will man wohl nicht auf jeder Seite haben.
News wird wohl auch meistens nur einmal pro Seite verwendet.
Bei Modulen wie Members siehts dann allerdings anders aus.
Oder einem ExtendedWYSIWYG.
Ist schon je nach Modul verschieden. Gebe ich Dir recht.
Ich meine aber eben für die Fälle, wo man es per Section anders haben will, muss man sich etwas einfallen lassen.
Gruß,
Stefek
-
Ich meine aber eben für die Fälle, wo man es per Section anders haben will, muss man sich etwas einfallen lassen.
Das ist primär erst mal ein Problem des jeweiligen Modules. Wenn es mehrfache Instanzierungen unterstützt, so gehört da auch seine Templatezuweisung dazu.
Der Kern kann und darf an dieser Stelle nicht eingreifen, da er ja von den Internas eines Modules keinerlei Informationen hat(und die auch nicht braucht). Den Kern interessiert nur die allgemeine Schnittstellengesta ltung zur Einbindung also derzeit der Aufruf von view, install, modify, add, delete, upgrade, uninstall und evt. include.php. Mehr nicht. Alles andere wäre bereits wieder eine unzulässige, harte Verflechtung von Kern und Modulen.
Es werden später mit Sicherheit diverse Helper-Klassen vom Kern angeboten werden die jedoch in der aktuellen Codeumgebung noch nicht vernünftig realisierbar sind.
-
Ich meine aber eben für die Fälle, wo man es per Section anders haben will, muss man sich etwas einfallen lassen.
Das ist primär erst mal ein Problem des jeweiligen Modules. Wenn es mehrfache Instanzierungen unterstützt, so gehört da auch seine Templatezuweisung dazu.
Ja, das ist schon mal klar.
Sag mal, was meintest Du denn oben mit Preset-System ?
Zusätzliche Presets => beherrschen des Presets-Systemes
Was ist da angedacht?
Gruß,
Stefek
-
Sollte keine Diskusion wert sein.
In den Dateien herscht Chaos! Funktionen zwischen P Tags und keine Struktur. Einfach alles durcheinander geworfen. Nichts eingerückt und auf Qualität keine Rücksicht genommen...
Ich erstelle grad ein Modul und es ist fürchterlich, dass ich mein Array, mein Object nicht einfach assignen und ans Templates übergeben kann. Damit kann ich es mir und dem Benutzer einfacher machen! Und der Code bleibt überschaubar und Strukturiert.
-
Nochmal schnell nachgefragt....
Wie ist denn der Stand?
Wird noch diskutiert ob eine, oder welche TE verwendet wird?
Ich würde ungern weiter machen, wenn ab morgen eine TE angeboten wird, die ich verwenden kann ;)
Es sind nur 3 Zeilen Code und ne Datei die hineingepackt werden müssten!
Und die Engine müsste ja nichtmal verwendet werden.
Falls es wirklich ( ganz ernsthaft! ), jemanden gibt, der überfordert ist, die Syntax von variablen und ne foreach ( mehr ist es im normalfall nicht ) zu erlernen, der kann immernoch PHP HTML murks zusammen flicken...
Lasst es bitte nur nicht wieder im Sande verlaufen!
-
Sollte keine Diskusion wert sein.
In den Dateien herscht Chaos! Funktionen zwischen P Tags und keine Struktur. Einfach alles durcheinander geworfen. Nichts eingerückt und auf Qualität keine Rücksicht genommen...
Ich erstelle grad ein Modul und es ist fürchterlich, dass ich mein Array, mein Object nicht einfach assignen und ans Templates übergeben kann. Damit kann ich es mir und dem Benutzer einfacher machen! Und der Code bleibt überschaubar und Strukturiert.
Blöde Frage, aber ich verstehe genau 0% von deinem Beitrag. :?
- Wo / in welchen Dateien herrscht Chaos
- Wo ist keine Struktur?
- Wo gibt es keine Einrückungen und keine Qualität?
- Wo kannst du nichts übergeben und mit was?
- Mit was wird der Code strukturiert?
Bitte verstehe das nicht als Angriff sondern schlichtweg, weil ich nicht weiß, was du meinst. Und nehme mal an, ich bin hier nicht der einzige.
-
@funas.
Wahrscheinlich hast Du es einfach noch nicht mitbekommen, aber es wird ab sofort die TE Twig im Paket angeboten.
Sie wird zwar noch nicht aktiv im Core verwendet, aber man kann sie bereits in Modulen verwenden. Soll der neue Standard werden.
Im aktuellen SVN ist sie drin, so auch in der nächsten WebsiteBaker Version 2.8.4
Gruß,
Stefek
-
twig wird bereits seit der 2.8.3er serie ausgeleifert
-
dann ist gut, hab nichts gesagt ;)
-
twig wird bereits seit der 2.8.3er serie ausgeleifert
Hm.. ja, aber die gegenwärtige Implementierung wurde erst vor 8 Monaten eingesetzt:
http://project.websitebaker2.org/projects/wb28x/repository/revisions/1686
Gruß,
Stefek
-
twig wird bereits seit der 2.8.3er serie ausgeleifert
Hm.. ja, aber die gegenwärtige Implementierung wurde erst vor 8 Monaten eingesetzt:
http://project.websitebaker2.org/projects/wb28x/repository/revisions/1686
// edit
im Download der 2.8.3 ist auch kein Twig im /include/ Ordner zu finden.
Gruß,
Stefek
-
Das stimmt.
Wann wird es denn veröffentlicht? Also < 1852 ?
Gibts da Zyklen oder so? :)
Gruß
-
Das stimmt.
Wann wird es denn veröffentlicht? Also < 1852 ?
Gibts da Zyklen oder so? :)
Gruß
Ich will heute einen ruhigen Sonntag verbringen, also sag ich lieber nix :-D
(Hatten wir schon letzte Woche das Thema.)
-
Schade..
Reden wir denn von einigen Tagen oder eher Wochen? :D
-
@funas: Wozu warten, packe doch einfach Twig in Deinen Modulordner und verwende es sofort. Ansonsten wird Dein Modul erst ab WB 2.8.4 laufen und alle früheren WB 2.8.x Versionen aussperren. Und die wenigsten werden gleich mit Veröffentlichung von WB 2.8.4 auf diese Version upgraden, das wird ne ganze Zeit dauern.
So hab ich das mit cwsoft-anynews, cwsoft-addon-file-editor und cwsoft-postits gehandelt. Links dazu gibts hier im athread ja zuhauf, müsste man halt mal lesen :wink:
-
Sollte doch nicht schwer sein, eben ein installierbares Twig-Modul zu bauen.
Ich bin eh dagegen, sowas unter include zu packen.
Es soll Menschen geben, die nicht 10 Module installieren wollen um eines verwenden zu können ;)
-
Sollte doch nicht schwer sein, eben ein installierbares Twig-Modul zu bauen.
Ich bin eh dagegen, sowas unter include zu packen.
Es soll Menschen geben, die nicht 10 Module installieren wollen um eines verwenden zu können ;)
Kann man aber genau so gut mit ausliefern, genau wie show_menu2. Muss auch keiner installieren.
-
Es gibt auch anderweitig Funktionen, die fest im Core verschachtelt sind, die viel mehr Sinn machen würden, wenn sie ausgelagert wären.
Z.B. die show_menu Funktion. Warum ist sie IM Core?
Breadcrumb und andere Funktionen, die allesamt initialisiert werden, auch wenn sie nicht benötigt werden.
(Das ist keine Kritik, sondern nur eine Idee: es müßte da gar nicht alles drin sein.)
Gruß,
Stefek
-
ja, ich werde jetzt Twig in mein Ordner packen.
-
Es gibt auch anderweitig Funktionen, die fest im Core verschachtelt sind, die viel mehr Sinn machen würden, wenn sie ausgelagert wären.
Z.B. die show_menu Funktion. Warum ist sie IM Core?
Breadcrumb und andere Funktionen, die allesamt initialisiert werden, auch wenn sie nicht benötigt werden.
(Das ist keine Kritik, sondern nur eine Idee: es müßte da gar nicht alles drin sein.)
Gruß,
Stefek
du fragst warum show_menu im core ist?
das liegt daran, dass es immer noch leute gibt - die liebend gerne das veraltete Teil verwenden.
Wenn es nun von WB in der 2.8er - Serie entfernt wird, ist das geschrei groß ;)
In der 2.8er Serie wird sich daran auch nichts ändern - dafür ist die 2.9er da
-
Das ist eine schwache Erklärung. Wenn es als Snippet mit ausgeliefert würde und beim Upgrade initialisiert, schreit auch keiner.
-
Hallo Daniel,
willkommen im Club der Megaperls :-D
Dietmar
-
willkommen im Club der Megaperls :-D
Was sind Megaperls? Leute, die vorgeben eine plausible Erklärung zu geben, die sich bei genauer Betrachtung als ein kläglicher Versuch entpuppt? :evil:
-
Hi,
hat doch Chio mal geschrieben " einer der Megaperls" hat geantwortet :-D
Was Daniel meinte, dass bisher immer im Core drauf geachtet wurde, abwärtskompatibel zu bleiben, da noch viele alte Templates im Umlauf sind.
Dietmar
-
Kompatibilität kann man auch beibehalten. Sagt doch keiner, dass es nicht wichtig wäre.
Einfach die Erklärung macht keinen Sinn, weil es über ein Snippet sichergestellt werden könnte.
-
Hallo,
Kompatibilität kann man auch beibehalten. Sagt doch keiner, dass es nicht wichtig wäre.
Einfach die Erklärung macht keinen Sinn, weil es über ein Snippet sichergestellt werden könnte.
Was ist das für ein Quatsch. Wenn ich auf eine neue Version upgrade und erst noch ein Snippet installieren muss, dass meine Seite wieder läuft, will ich von der neuen Version schon gleich gar nix mehr wissen.
Laßt das uralte show_menu ruhig mal in der 2.8 er Reihe noch drinne. Die paar Zeilen Code schaden niemand. Und ich kann momentan keinerlei Mehrwert für WB erkennen, wenn das Teil rausgenommen wird.
Ich bin schon verwundert, dass gerade die, die sich immer über die Bevormundung der Dev's über die Community beschweren, jetzt einen solchen Vorschlag bringen. Lasst es doch den mündigen WB-User entscheiden, ob er das Teil noch einsetzen will oder nicht.
Matthias
-
Na keine Sorge, es wird zur 2.8.4 noch nichts endgültig herausgenommen, was nicht schon Monate vorher angekündigt ware.
Allerdings wird bei der 2.8.4 ein neues Teil dazukommen: Eine sehr, sehr lange 'Deprecated-List' zur 2.9. Aber das sollte eigentlich jedem längst klar sein, dass es keine Runderneuerung geben kann, ohne die alten Reifen und das Altöl dabei zu entsorgen. ;-)
-
Was ist das für ein Quatsch. Wenn ich auf eine neue Version upgrade und erst noch ein Snippet installieren muss, dass meine Seite wieder läuft, will ich von der neuen Version schon gleich gar nix mehr wissen.
Wer spricht den von installieren?
Ich habe das geschrieben:
Das ist eine schwache Erklärung. Wenn es als Snippet mit ausgeliefert würde und beim Upgrade initialisiert, schreit auch keiner.
-
@stefek
uups, hab ich wohl überlesen.
Kann aber immer noch keinen Vorteil darin erkennen, warum das anstatt als modul als snipppet rein soll.
Matthias
-
uups, hab ich wohl überlesen.
Kein Problem. Kann passieren.
Kann aber immer noch keinen Vorteil darin erkennen, warum das anstatt als modul als snipppet rein soll.
Du meinst, "anstatt im Core als Snippet"?
Brauchen wir uns ehrlich gesagt nicht näher Kopf drum machen.
Wir könnten uns einfach darauf einigen, dass einfach nichts dagegen sprechen würde.
Es wäre einfach eine bessere, sauberere Trennung zwischen Core und Zusatzfunktionen.
Immerhin werden alle Funktionen der frontend.functions. php geladen, auch wenn sie nicht verwendet werden - mag es auch nicht zu viel Speicher verbrauchen, ganz "sauber" ist diese Variante aber nicht.
Gruß,
Stefek
-
Es ist immer eine Gratwanderung, was im Core ist und was nicht.
WB ist so aufgebaut wie es ist. show_menu war Core, show_menu2 ein Community-Modul.
Und durch dieses "aufbohren" die Jahre über ist WB eben so gewachsen, wie wir es - bis vor kurzem zumindest - gekannt haben.
Was nun im Core ist und nicht kann man trefflich streiten. Auch was mitgeliefert wird im Download-Paket und was nicht. Moderne Systeme z.B. haben eine Core-Komponente, die genau eines macht: gar nichts. Oder besser: nichts für außen sichtbares. Benutzerverwaltung, Seiten, Optionen - alles Module. Noch gar nicht zu sprechen vom Framework drunter.
Daher denke ich sollte man es nicht übertreiben mit der Modulierung, und die Gratwanderung gehen, die WB schon immer gegangen ist. Zumindest für die aktuellen Versionen.
-
Hallo,
naja, man kann die Sache auch von einer anderen Seite aus betrachten. Gerade bei JQuery sind nicht immer alle Versionen kompatibel zur nächsten. Insofern kann es durchaus sinnvoll sein eine geprüfte und freigegebene Version mit dem Paket auszuliefern. Damit ist sichergestellt, dass dann auch alles läuft. Klar muss man dann unter Umständen warten bis zur nächsten WB Version.
Aber mal ehrlich, was haben wir denn für einen Nutzerkreis. Die große Masse zieht sich WB installiert es und erwarted, dass alles läuft. Wenn ein Update herauskommt wird das installiert und man erwartet wieder dass alles läuft. Und der Normaluser braucht auch nicht ständig die neueste und aktuellste Version. Für den ist die Hauptsache, dass das System funktioniert. Wenn die ganzen includes als Module angeboten werden und jeder da kreuz und Quer dann die Module aktualisiert sind früher oder später Inkompatibiltäten vorprogrammiert.
Und eines sollte man auch ganz klarstellen. Diejenigen, die sich ein bisserl tiefer in die Materie einarbeiten, können JQuery, Twig und was sonst noch alles im includes Verzeichnis liegt doch jederzeit manuell aktualisieren. Dazu braucht es kein Modul. Das Ganze als Module auszulagern haben andere ja schon versucht, über die Ergebnisse schweige ich lieber. Da gefällt mir die Philosophie von WB deutlich besser. Und zwar sowohl die bestehende als auch die sich entwickelnde.
Matthias
-
Hallo,
Wir reden hier aber von Twig als Template Engine, und die Frage, ab wann es denn eigentlich offiziell verfügbar ist,
Nun nachdem es seit einigen Revisionsnummern im includes-Verzeichnis von WB liegt, und jetzt auch noch einmal auf die aktuelle Version 1.11.1 aktualisiert wurde, gehe ich schwer davon aus, dass dies spätestens mit der Veröffentlichung von WB 2.8.4 offiziell sein wird.
Matthias
-
Das sagten schon einige. Bleibt die Frage nach dem "Wann ist das?"
Das Ziel-Datum kannst du hier erkennen:
klick me (http://project.websitebaker2.org/projects/wb28x/roadmap).
Es werden gerade die letzten Fehler im Upgrade-Script behoben so wie eine kleine aber feine klasse hinzugefügt.
Sollten dann keine Bugs mehr gefunden werden - wird sie natürlich öffentlich :)
-
Sehr gut !
-
Es werden gerade die letzten Fehler im Upgrade-Script behoben so wie eine kleine aber feine klasse hinzugefügt.
Bitte lasst das die Leute vorher auch mal außerhalb vom Betatesterkreis testen. WB ist mittlerweile zu oft mit kurzfristigen Änderungen bei Releases auf die Schnauze geflogen, wenn es jetzt eh nur noch 1 Version / Jahr gibt, sollte die auch dann Niet- und Nagelfest sein.
Aber mal ehrlich, was haben wir denn für einen Nutzerkreis. Die große Masse zieht sich WB installiert es und erwarted, dass alles läuft. Wenn ein Update herauskommt wird das installiert und man erwartet wieder dass alles läuft. Und der Normaluser braucht auch nicht ständig die neueste und aktuellste Version. Für den ist die Hauptsache, dass das System funktioniert. Wenn die ganzen includes als Module angeboten werden und jeder da kreuz und Quer dann die Module aktualisiert sind früher oder später Inkompatibiltäten vorprogrammiert.
Himmel nochmal, was habt ihr nur für eine Vorstellung von den WB Usern. Ich will es gar nicht wissen, ich reg mich eh nur auf. Ich stelle einen Mitgliedsantrag bei der FDP für den Verein.
-
Himmel nochmal, was habt ihr nur für eine Vorstellung von den WB Usern. Ich will es gar nicht wissen, ich reg mich eh nur auf. Ich stelle einen Mitgliedsantrag bei der FDP für den Verein.
Bleibt sachlich - also back to topic oder es wird geschlossen!
-
Bääh, Dwoo....
Dwoo ist wohl der Hauptgrund, warum ich mir Lepton oder die anderen Froks nie installiert habe.
Nicht, weil ich nicht noch eine TE Sprache lernen müßte (die sind schnell gelernt), sondern weil Twig so viel kompakter und besser ist als Dwoo.
Ich bin sehr froh, dass Twig in WB reingekommen ist. Wessen Idee nochmal? cwSoft glaube ich.
-
Jetzt weiß ich gar nicht mehr,
ob ich die Forks deswegen nicht mag, weil da Dwoo drin ist oder
ob ich Dwoo nicht mag, weil es in den Forks drin ist.
:|
Was soll's, ich muss ja keins von beiden verwenden :wink:
-
Du gehörst offensichtlich nicht zur Zielgruppe der guten Nachricht.
Als erstes: diese "gute Nachricht", dass nämlich Dwoo weiterentwickelt wird, betrifft WB CMS wenig.
Ich sehe aber, cwSoft hat zuvor die Frage an Dich gestellt, ob Du wüßtest, ob Dwoo weiterentwickelt wird.
Gratuliere. Dwoo wird weiterentwickelt.
Es erstaunt mich, daß die [Forks] neuerdings in jedem Thread zur Sprache kommen...
Na ja, nicht in jedem - aber warum freust Du Dich nicht?
Früher wurde jede Erwähnung eines Forks unterbunden und anstatt Dich zu bedanken, hackst Du an dem Ursprungsprojekt rum.
Schäm Dich. Da haben sich Leute sogar dafür eingesetz, dass Moorhuhnjagden aufhören, aber Du scheinst das alles wahrscheinlich für selbstverständlich zu halten. Ganz schön *.
-
Da kannst Du mal sehen, wie hoch meine Toleranz ist.