nicht angemeldet
Karl Heinz
Felix Riesterer
Rolf B
Rolf B
Gunnar Bittersmann
Felix Riesterer
Gunnar Bittersmann
Gunnar Bittersmann
dedlfix
Gunnar Bittersmann
dedlfix
Hallo,
ich habe mich die letzten Tage ein bisschen mit dem Online-Shop System Shopware beschäftigt. Laut Wikipedia ist Shopware in der Skriptsprache PHP programmiert. Ich bin nun her gegangen und habe mit Hilfe einer CSV-Datei Artikel ins Shopware-System importiert. Die Daten mussten vor dem Import modifiziert werden. Für solche Modifizierungen stellt Shopware im Backend ein Eingabefenster zur Verfügung, in welches man Code eingeben kann, der diese Modifizierungen durchführt. Ich hätte nun eigentlich erwartet, dass man hier PHP-Code eingeben muss, zu meinem Erstaunen habe ich dann festgestellt, dass man hier keinen PHP-Code eingeben muss sondern stattdessen Smarty-Code. Smarty war mir bisher kein Begriff. Durch googlen habe ich nun herausgefunden, dass Smarty eine Template Engine ist. Was eine Template Engine ist habe ich leider auch nicht gewusst, deshalb habe ich erneut gegooglet. Wenn ich das richtig verstanden habe, dann ist es mit einer Template Engine besonders einfach den Code des Kernsystems und den Code der GUI, welche auf dem Kernsystem aufsetzt, von einander zu trennen (Stichwort Model-View-Controller).
Dazu ein paar Fragen:
Viele Grüße
Gunnar Bittersmann
- Des weiteren habe ich gelesen, dass es bezogen auf Smarty sowohl Befürworter als auch Gegner gibt.
Oh! Endlich wieder ein Glaubenskrieg!
Nutzt man Smarty hat das meines Erachtens nur Nachteile
Ich selbst nutze es (für meinen Krempel) aus den von Dir genannten Gründen nicht.
Aber der Grund hier stimmt nicht immer und nicht für jeden:
Smarty ist ein PHP Aufsatz und macht das System deshalb langsamer.
Smarty cacht. Da "PHP" von manchen auch mit "pubertierende Hauptschüler programmieren" übersetzt wird ist die Implementierung eines aufgabenbezogenen, brauchbaren Caches (oder auch nur die Aktivierung des opcaches) für manche eine nicht zu bewältigende Herausforderung. Wer sich also um das Cachen keine eigenen Gedanken will (oder soll, darf) oder es halt (noch) nicht kann, der ist mit Smarty (oft) besser bedient als ohne.
Für diejenigen, die aber gerne selbst die letzte Millisekunde rauskitzeln, ist Smarty (unter isolierender Betrachtung nur dieses Umstands) lediglich ein, den Interpreter beschäftigender Überbau.
Das gilt übrigens für viele Bibliotheken vieler Programmiersprachen.
Im Handbuch steht übrigens der wichtigste Anwendungszweck:
Smarty ist eine Template-Engine für PHP. Genauer gesagt erlaubt es die einfache Trennung von Applikations-Logik und Design/Ausgabe. Dies ist vor allem wünschenswert, wenn der Applikationsentwickler nicht die selbe Person ist wie der Designer.
Dann spart es viele Mails, viele Telefongespräche und viele Blicke ins Error-Log.
Lieber ursus,
Oh! Endlich wieder ein Glaubenskrieg!
:-)
Für diejenigen, die aber gerne selbst die letzte Millisekunde rauskitzeln, ist Smarty (unter isolierender Betrachtung nur dieses Umstands) lediglich ein, den Interpreter beschäftigender Überbau.
Mal ganz abseits von Template-Engines. Wenn man sein Script so baut, dass es immer alle Teilscripte inkludiert und eben nicht situationsabhängig kompiliert, hat man dann nach dem zweiten Seitenaufruf weniger Kompilierungsarbeit, weil PHP das letzte Kompilat gecached hat?
Liebe Grüße,
Felix Riesterer.
Mal ganz abseits von Template-Engines. Wenn man sein Script so baut, dass es immer alle Teilscripte inkludiert und eben nicht situationsabhängig kompiliert, hat man dann nach dem zweiten Seitenaufruf weniger Kompilierungsarbeit, weil PHP das letzte Kompilat gecached hat?
Theorethisch? Ja.
Praktisch hat man aber oft nur eine begrenzte Anzahl von Dateien selbst im opcache.file_cache. Außerdem nützt das nicht viel, denn auch die kompilierten Skripte (aus /path/foo.php wird ini_get(opcache.file_cache)/path/foo.php.bin) werden dann includiert und verbrauchen unnötig Speicher!
Bei Nutzung "ausreichend" atomisierter Libs mit manchmal tausenden kleinster Dateien ...
Matthias Apsel<?php
/* foo3.php */
require LIBDIR.'foo.php';
function foo3( $bar ) {
return foo( $bar, 3 );
}
...sind die Grenzen (opcache.max_accelerated_files=10000, opcache.memory_consumption=128) "schnell gerissen".
Man kann sich aber einen "toten" (sonst nutzlosen) Wrapper mit allen Libs bauen und den selbst einmalig manuell aufrufen. (Aufpassen, php hat für das Ausführen in der Konsole oder unter dem Apache verschiedene INIs!. Falls man es liebt, sich unnötig Arbeit zu machen...
Hallo ursus,
Smarty cacht.
Ja, aber anders als Du meinst, und jein, Smarty compiliert. Es übersetzt das Smarty-Markup in PHP und führt dann das PHP aus.
Wenn man also $tpl->display("foo.tpl") aufruft, dann guckt Smarty im Compilat-Ordner nach einer Datei namens "%%17^175^17524F68%%foo.tpl.php" (oder so) und guckt, ob die neuer ist als foo.tpl. Wenn ja, wird einfach nur die vorhandene PHP Datei includiert. Andernfalls läuft der Compiler an und erzeugt das Compilat neu.
Das Ergebnis kann dann von Bytecode-Caches gecached werden.
PROBLEM BEI DER SACHE: Man muss seiner Webanwendung erlauben, Code zu generieren und diesen generierten Code auszuführen. Das ist ein Sicherheitsrisiko und sollte nur in Testumgebungen gemacht werden. In Smarty 3 gibt es die compileAllTemplates-Methode; damit kann man sicherstellen, dass alle Templates übersetzt sind und auf der produktiven Webseite nicht compiliert werden müssen.
Caching in Smarty ist etwas anderes. Man kann einschalten, dass der Output eines Templates teilweise oder vollständig in einer Datei gespeichert wird, und bei erneutem Abruf aus der Datei geholt wird. Bei Templates die längere Render-Zeit haben, sich aber nur marginal ändern, kann das viel Zeit sparen.
Rolf
Hallo ursus,
Moin Rolf!
Smarty cacht.
Ja, aber anders als Du meinst, und jein, Smarty compiliert. Es übersetzt das Smarty-Markup in PHP und führt dann das PHP aus.
...
Caching in Smarty ist etwas anderes. Man kann einschalten, dass der Output eines Templates teilweise oder vollständig in einer Datei gespeichert wird, und bei erneutem Abruf aus der Datei geholt wird.
Anders als Du vermutest meinte ich genau DAS. Deshalb schrieb ich auch:
ist die Implementierung eines aufgabenbezogenen, brauchbaren Caches (oder auch nur die Aktivierung des opcaches) für manche eine nicht zu bewältigende Herausforderung.
Aus dem "ODER die Aktivierung des opcaches" sollte für den "normal verständigen und ausreichend aufmerksamen Leser" (Zitat von Mack, R. a. LG Berlin) hervorgehen, dass der opcache (PHP-Dateien werden von diesem als Bytecode abgelegt) NICHT gemeint war. Was hingegen ein Outout-Cache ist und wie man so einen "baut" weiß ich spätestens seit anno 2012.
Anlass zu dem Skript war damals übrigens schon damals eine Diskussion über Smarty. Ich dachte "Hm. Das kann ich auch, vielleicht sogar besser."
Hallo ursus,
autsch. Man sollte sich nicht mit gerichtserfahrenen Genaulesern anlegen 😉
Rolf
@@Karl Heinz
1. Smarty ist ein PHP Aufsatz und macht das System deshalb langsamer.
Wenn man gut strukturierten Code schreibt (OOP), springt man auch innerhalb von PHP von Methode zu Methode und macht das System langsamer. Schneller wäre Spaghetti-Code – das will man aus guten Gründen nicht. Lesbarkeit und Wartbarkeit des Codes gehen hier vor der geringen(!) Geschwindigkeitseinbuße.
Dasselbe gilt für eine Template-Engine: wenn’s das System besser verständlich = besser wartbar macht, dann her damit!
2. Verwendet man zusätzlich Smarty muss man den Syntax von PHP UND Smarty lernen.
Die Syntax, weiblich.
Und so kompliziert und umfangreich ist die Syntax einer Template-Sprache nun auch nicht; der Lernaufwand ist minimal.
Außerdem kommt eine Template-Engine an der Schnittstelle von Backend und Frontend zum Einsatz – da, wo Daten ins HTML geschrieben werden. Also an der Stelle, wo sich die Arbeit von Backend-Entwicklern und Frontend-Entwicklern überlappt. Wenn da eine Template-Engine zum Einsatz kommt, muss ein Frontend-Entwickler überhaupt kein PHP lernen, sondern nur die Template-Sprache (zusätzlich zu HTML, CSS und ggfs. JavaScript, versteht sich).
Würde man nur PHP verwenden
Das heißt: PHP als Template-Engine. Kann man machen – dann aber bitte in der Form, wie ich sie hier für die Stelle, wo HTML generiert wird, immer predige: Keine HTML-Tags mit echo generieren; PHP in HTML schachteln, nicht andersrum. Also nicht
<?php
echo "<output>$answer</output>";
?>
oder
<?php
echo '<output>' . $answer . '</output>';
?>
sondern
<output><?php echo $answer ?></output>
oder auch kurz
<output><?= $answer ?></output>
Zusammen mit den Kontrollstrukturen in alternativer Syntax(!) hat man dann genau die Mächtigkeit einer Template-Sprache.
<ul>
<?php foreach ($results as $result): ?>
<li><?= htmlspecialchars($result) ?></li>
<?php endforeach; ?>
</ul>
in Smarty:
<ul>
{foreach $results as $result}
<li>{$result|escape}</li>
{/foreach}
</ul>
Kleiner Pluspunkt für die Template-Sprache: die einfachere Syntax.
Großer Pluspunkt für die Template-Sprache: der beschränkte Sprachumfang. Man kann nur das verwenden, was man an der Stelle (der Ausgabe) verwenden sollte. Bei PHP könnte man in Versuchung kommen, da Dinge zu tun, die nichts mit der Ausgabe zu tun haben. Der Einsatz einer Template-Engine zwingt zu sauberer Programmierung.
LLAP 🖖
Lieber Gunnar,
<output><?= $answer ?></output>
wo wird da kontext-gerecht kodiert?
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
<output><?= $answer ?></output>wo wird da kontext-gerecht kodiert?
Ich bin stillschweigend davon ausgegangen, dass $answer das Ergebnis einer (7½ Millionen Jahre dauernden) Berechnung ist und 42 keiner weiteren Behandlung bedarf.
Wenn $answer ein String ist, in dem HTML-Sonderzeichen auftreten können, insbesondere eine Nutzereingabe oder ein Datenbankeintrag zweifelhafter Herkunft, dann muss es natürlich
<output><?= htmlspecialchars($answer) ?></output>
heißen; in Smarty
<output>___SMARTY0___</output>
Ich hatte noch überlegt, das zu erwähnen; mich aber dann dagegen entschieden. War vielleicht nicht die beste Entscheidung.
LLAP 🖖
PS: Ich hab das im unteren Teil jetzt mal ergänzt.
@@Gunnar Bittersmann
in Smarty
<output>___SMARTY0___</output>
Warum muss man das eigentlich tun? Warum escapet Smarty nicht schon von Haus aus?
Template-Engines werden ja verwerdet, um Daten ins HTML zu schreiben; nicht um HTML-Tags zu generieren. Es gibt zwar Fälle, wo man nicht unbedingt escapen muss (wenn bspw. $anwser das Ergebnis einer numerischen Berechnung ist); mir will aber kein Fall einfallen, wo man nicht escapen darf.
Warum wird ___SMARTY0___ nicht gleich in htmlspecialchars($answer) übersetzt?
Und jetzt, wo ich die Frage einmal aufgeschrieben habe, fällt mir auch die Antwort ein: 42.
Genauer: Der Einsatz von Template-Engines ist nicht auf Generierung von HTML beschränkt. Es könnten bspw. auch JavaScript- oder CSS- oder JSON- oder CSV-Ressourcen per Template-Engine generiert werden. In dem Fall wäre htmlspecialchars() falsch und andere Filter angesagt.
LLAP 🖖
Tach!
Genauer: Der Einsatz von Template-Engines ist nicht auf Generierung von HTML beschränkt. Es könnten bspw. auch JavaScript- oder CSS- oder JSON- oder CSV-Ressourcen per Template-Engine generiert werden.
Oder alles in einer HTML-Ressource mit style- und script-Abschnitten drin, am besten noch mit Javascript Strings für innerHTML erzeugt.
dedlfix.
Warum wird {$answer} nicht gleich in htmlspecialchars($answer) übersetzt?
Weil $answer schon einen mit htmlspecialchars() bereinigten String enthalten könnte.
@@ursus contionabundo
Warum wird {$answer} nicht gleich in htmlspecialchars($answer) übersetzt?
Weil $answer schon einen mit htmlspecialchars() bereinigten String enthalten könnte.
Wenn man nicht erst bei der Ausgabe, sondern schon vorher escapet, macht man aber auch was falsch.
LLAP 🖖
@@ursus contionabundo
Warum wird {$answer} nicht gleich in htmlspecialchars($answer) übersetzt?
Weil $answer schon einen mit htmlspecialchars() bereinigten String enthalten könnte.
Wenn man nicht erst bei der Ausgabe, sondern schon vorher escapet, macht man aber auch was falsch.
Womöglich.
Womöglich aber hat man als Programmierer, weil man sich nicht auf den Designer verlassen will, alle zur Ausgabe vorgesehenen Variablen z.B. mit
$GLOBALS['tpl']['intAnswer'] = (int)$answer;
"entgiftet" angelegt und sodann überflüssiges zur Vermeidung von Missverständnissen mit
unset( $answer );
entsorgt.
hallo
Wenn man nicht erst bei der Ausgabe, sondern schon vorher escapet, macht man aber auch was falsch.
Was ist korrekt?
return( "<p>" . htmlspecialchars( $textContent ) . "</p>" )
oder
return( htmlspecialchars( "<p>" . $textContent . "</p>" ) )
Lieber beatovich,
return( "<p>" . htmlspecialchars( $textContent ) . "</p>" )
oder
return( htmlspecialchars( "<p>" . $textContent . "</p>" ) )
weder noch:
return( htmlspecialchars( "<p>$textContent</p>" ) );
Beachte das Semikolon am Ende!
Nein, Scherz beiseite. Es ist die Frage, was in $answer steht. Wird HTML-Code generiert, oder ist das garantiert nur plain/text? Im letzteren Falle wäre Dein erster Versuch (mit Semikolon!) der korrekte Ansatz. Dein zweiter Versuch macht HTML-Code auf der Seite menschenlesbar, indem < und > zu XML-Entitäten konvertiert werden:
return( htmlspecialchars( "<p>$textContent</p>" ) );
ergibt:
<p>$textContent</p>
Liebe Grüße,
Felix Riesterer.
Tach!
Wenn da eine Template-Engine zum Einsatz kommt, muss ein Frontend-Entwickler überhaupt kein PHP lernen, sondern nur die Template-Sprache (zusätzlich zu HTML, CSS und ggfs. JavaScript, versteht sich).
Man muss ja PHP nicht komplett lernen, um Templates damit schreiben zu können. Den Aufwand, die Template-Engine-Syntax zu lernen und die vergleichbaren PHP-Elemente, betrachte ich nicht als allzu unterschiedlich.
Zusammen mit den Kontrollstrukturen in alternativer Syntax(!) hat man dann genau die Mächtigkeit einer Template-Sprache.
Ob alternative Syntax oder Klammern sehe ich als eine Sache der persönlichen Vorliebe. Hat beides seine Vor- und Nachteile.
<ul> <?php foreach ($results as $result): ?> <li><?= htmlspecialchars($result) ?></li> <?php endforeach; ?> </ul>in Smarty:
<ul> ___SMARTY0___ <li>___SMARTY1___</li> ___SMARTY2___ </ul>
Und siehe da, so großartig unterscheidet sich PHP in diesem Beispiel nicht von Smarty.
Großer Pluspunkt für die Template-Sprache: der beschränkte Sprachumfang.
Der große Pluspunkt ist gleichzeitig auch ein großer Minuspunkt: die eingeschränkte Flexibilität, wenn man Lösungen abseits dessen braucht, was die Template-Engine mitbringt. Andererseits ist Smarty sehr mächtig und sein Sprachumfang nicht allzu eingeschränkt. Außerdem kann man Smarty mit Plugins erweitern und es damit noch weniger eingeschränkt machen.
Man kann nur das verwenden, was man an der Stelle (der Ausgabe) verwenden sollte.
Anders formuliert: man kann nur das verwenden, was die Template-Engine-Entwickler als das angesehen haben, was man braucht. (Generell gesprochen, Smarty als Ausnahme ist ja recht flexibel gestaltet.)
Bei PHP könnte man in Versuchung kommen, da Dinge zu tun, die nichts mit der Ausgabe zu tun haben.
Speziell mit Smarty kann man das auch. Die Sprache kennt Variablen, man kann rechnen, man hat Schleifen und if-else-Kontrollstrukturen. Selbst Funktionen kann man sich definieren. Man kann damit eine ganze Menge Aufgaben erledigen, die man besser vor dem Aufruf der Template-Engine erledigt.
Der Einsatz einer Template-Engine zwingt zu sauberer Programmierung.
Das sehe ich noch nicht so. Die grundlegende Philosophie ist zwar, dass man für das Template eine separate Datei anlegt und man vor dessen Aufruf erstmal alle Werte zusamengesammelt haben muss - also das gute alte EVA-Prinzip - aber Smarty bietet auch an, Strings als Tempate-Quelle zu verarbeiten, und es hindert mich auch nicht daran, mitten im V-Teil mal eben schnell ein Template ausgeben zu lassen und dann mit der Verarbeitung der Daten fortzufahren. Die Disziplin muss schon von einem selbst kommen.
dedlfix.
@@dedlfix
Man muss ja PHP nicht komplett lernen, um Templates damit schreiben zu können. Den Aufwand, die Template-Engine-Syntax zu lernen und die vergleichbaren PHP-Elemente, betrachte ich nicht als allzu unterschiedlich.
Bei PHP käme da erschwerend hinzu, ohne Kenntnis der Sprache zu entscheiden, welchen Teil der Sprache man lernen müsste. Da sieht man schnell den Wald vor lauter Bäumen nicht.
man hat Schleifen und if-else-Kontrollstrukturen.
Natürlich sollte eine Template-Engine soetwas haben – für Ausgabelogik. Sowas wie
<nav>
<ul>
___SMARTY0___
<li>
<a
___SMARTY1___
aria-current="page" tabindex="0"
___SMARTY2___
href="___SMARTY3___"
___SMARTY4___
>
___SMARTY5___
</a>
</li>
___SMARTY6___
</ul>
</nav>
will man mit einer Template-Engine tun können.
also das gute alte EVA-Prinzip - aber Smarty bietet auch an, Strings als Tempate-Quelle zu verarbeiten, und es hindert mich auch nicht daran, mitten im V-Teil mal eben schnell ein Template ausgeben zu lassen und dann mit der Verarbeitung der Daten fortzufahren.
Da gehört ja schon kriminelle Energie dazu, das zu tun.
Die Disziplin muss schon von einem selbst kommen.
OK. Aber eine Template-Engine schubst einen schon eher in die richtige Richtung als das PHP tut (nämlich gar nicht).
LLAP 🖖
Tach!
Man muss ja PHP nicht komplett lernen, um Templates damit schreiben zu können. Den Aufwand, die Template-Engine-Syntax zu lernen und die vergleichbaren PHP-Elemente, betrachte ich nicht als allzu unterschiedlich.
Bei PHP käme da erschwerend hinzu, ohne Kenntnis der Sprache zu entscheiden, welchen Teil der Sprache man lernen müsste. Da sieht man schnell den Wald vor lauter Bäumen nicht.
Dasselbe könnte man auch von Smarty behaupten. Auch da ist viel Zeugs dabei, das man nicht als Grundlage benötigt. Andererseits ist genau der benötigte Teil von PHP üblicherweise der Start-Teil von Einstiegstutorials: etwas ausgeben, Variablen verwenden, Kontrollstrukturen.
man hat Schleifen und if-else-Kontrollstrukturen.
Natürlich sollte eine Template-Engine soetwas haben – für Ausgabelogik. Sowas wie
<nav> <ul> ___SMARTY0___ <li> <a ___SMARTY1___ aria-current="page" tabindex="0" ___SMARTY2___ href="___SMARTY3___" ___SMARTY4___ > ___SMARTY5___ </a> </li> ___SMARTY6___ </ul> </nav>will man mit einer Template-Engine tun können.
Wer ist man und warum will der das? Ein Frontend-Ersteller, der keine PHP-Kenntnisse hat oder ein PHP-Entwickler, der all die Spachelemente auch in PHP vorfindet oder noch ein anderer?
also das gute alte EVA-Prinzip - aber Smarty bietet auch an, Strings als Tempate-Quelle zu verarbeiten, und es hindert mich auch nicht daran, mitten im V-Teil mal eben schnell ein Template ausgeben zu lassen und dann mit der Verarbeitung der Daten fortzufahren.
Da gehört ja schon kriminelle Energie dazu, das zu tun.
Und dabei hab ich noch nicht mal all die Möglichkeiten aufgezählt mit Smarty chaotische Templates und ebensolche Ausgaben zu erzeugen.
dedlfix.
@@dedlfix
… will man mit einer Template-Engine tun können.
Wer ist man und warum will der das? Ein Frontend-Ersteller, der keine PHP-Kenntnisse hat
Ja, die.
oder ein PHP-Entwickler, der all die Spachelemente auch in PHP vorfindet
Nein. PHP-Entwickler (Backend-Entwickler) will man nicht daran lassen, HTML-Code zu generieren. Und man ist in dem Fall alle.
Die Diskussion hatten wir sicher schon mal. Und ja, es gibt Ausnahmen. Es gibt PHP-Entwickler, die mehr als ein HTML-Element (div) kennen. Und es mag sogar welche geben, die schon mal was von ARIA gehört haben. Aber die sind wohl in der verschwindenden Minderzahl.
LLAP 🖖
Tach!
… will man mit einer Template-Engine tun können.
Wer ist man und warum will der das? Ein Frontend-Ersteller, der keine PHP-Kenntnisse hat
Ja, die.
oder ein PHP-Entwickler, der all die Spachelemente auch in PHP vorfindet
Nein. PHP-Entwickler (Backend-Entwickler) will man nicht daran lassen, HTML-Code zu generieren. Und man ist in dem Fall alle.
Das klingt für mich recht hochnäsig, als ob alle Frontend-Entwickler wüssten, wie man perfektes HTML & Co. erstellt. Daran glaube ich erst, wenn ich davon überzeugt bin, dass alle Backender optimal programmieren können.
dedlfix.
Nein. PHP-Entwickler (Backend-Entwickler) will man nicht daran lassen, HTML-Code zu generieren. Und man ist in dem Fall alle.
Das klingt für mich recht hochnäsig, als ob alle Frontend-Entwickler wüssten, wie man perfektes HTML & Co. erstellt. Daran glaube ich erst, wenn ich davon überzeugt bin, dass alle Backender optimal programmieren können.
Also wenn man schon "Backender" und "Frontender" hat, dann sollte man schon davon ausgehen, dass man den "Backender" nicht ans "Frontend", den "Frontender" nicht ans "Backend" und mich auf gar keinen Fall an Grafiken oder an die äußere Gestaltung des gemeinsamen Bemühungsergebnisses ranlassen will.
Meine Ergebnisse auf den fremden Feldern [Frontend, Gestaltung, Grafiken] beweisen das.
Selbst wenn die Kenntnisse ausreichen sollten, hätte jeder (Echt gleichberechtigt sein wollende Damen werden sich automatisch mit angesprochen fühlen!) a) weniger Kopfschmerzen und b) mehr Zeit für die Fortbildung auf dem eigenem Spezialgebiet, wenn er denn nur das tut womit er sich wirklich auskennt.
@@dedlfix
Nein. PHP-Entwickler (Backend-Entwickler) will man nicht daran lassen, HTML-Code zu generieren. Und man ist in dem Fall alle.
Das klingt für mich recht hochnäsig
Sollte es nicht. Ich hab durchaus Respekt für die Arbeit von PHP-Entwicklern u.a. Backendern. Sie schreiben weitaus besseren Code als ich das je könnte. (Vielleicht wäre ich gar nicht mal zu doof dafür; meine Interessen liegen bloß woanders.)
Nur sollten sie eben das tun, worin sie gut sind. Und nicht das, worin sie nicht gut sind: HTML zu schreiben (oder CSS).
als ob alle Frontend-Entwickler wüssten, wie man perfektes HTML & Co. erstellt.
Definiere „Frontend-Entwickler“! Ich würde JavaScript-Programmierer mit den Backendern in einen Topf werfen. Oder anders gesagt: die Grenze anders ziehen: business logic vs. user interface. Bloß weil die Geschäftslogik heutzutage oft clientseitig läuft, ist das für mich nicht „im Frontend“.
Was so weitläufig „Frontend-Entwickler“ genannt wird, hat für mich mit Frontend-Entwicklung (UI-Entwicklung) nichts zu tun. Und so wissen tatsächlich viele sog. „Frontend-Entwickler“ nicht, wie man perfektes HTML & Co. erstellt.
Daran ist nicht schlimmes. Nur sollten sie eben das tun, worin sie gut sind: Geschäftslogik zu programmieren. Und nicht das, worin sie nicht gut sind: HTML zu schreiben (oder CSS).
LLAP 🖖
Hallo Gunnar Bittersmann,
Backendern
Da hab ich doch direkt „Backendeern“ gelesen.
Bis demnächst
Matthias
moin,
Smarty ist nur die Templatemaschine (TE). Was eine Solche an sich betrifft, ist sie unumgänglich zum Produzieren von lesbaren, skalierbaren und wartungsfreundlichen Code in Teamarbeit.
Enfach mal was damit machen!
Tach!
Smarty ist nur die Templatemaschine (TE). Was eine Solche an sich betrifft, ist sie unumgänglich zum Produzieren von lesbaren, skalierbaren und wartungsfreundlichen Code in Teamarbeit.
Man kann genauso gut lesbaren wie unlesbaren, guten wie schlechten, schnellen wie langsamen Code mit und ohne TE erstellen. Eine TE allein bringt noch keine Verbesserung ins Team, wenn das Team nicht von sich aus bereits Qualität liefern kann.
dedlfix.
Tach!
Smarty ist nur die Templatemaschine (TE). Was eine Solche an sich betrifft, ist sie unumgänglich zum Produzieren von lesbaren, skalierbaren und wartungsfreundlichen Code in Teamarbeit.
Man kann genauso gut lesbaren wie unlesbaren, guten wie schlechten, schnellen wie langsamen Code mit und ohne TE erstellen. Eine TE allein bringt noch keine Verbesserung ins Team, wenn das Team nicht von sich aus bereits Qualität liefern kann.
Wahrscheinlich hast noch noch nie ein Framework in C entwickelt, sonst würdest Du solche Sprüche nicht gebetsmühlenartig und in Folge herunterleiern.
Schönen Sonntag.
Tach!
Wahrscheinlich hast noch noch nie ein Framework in C entwickelt, sonst würdest Du solche Sprüche nicht gebetsmühlenartig und in Folge herunterleiern.
Mir und andern gebetsmühlenartig und in Folge heruntergeleiert Unkenntnis vorzuwerfen, hilft mir nicht dabei, deine Gedankengänge nachvollziehen zu können, wenn ich mit meinen Gedankengängen zu einem anderen Ergebnis komme.
Ich wüsste nicht, wie die Entwicklung eines (Web?)Frameworks in C zu anderen Erkenntnissen führen sollte, als dass man mit jedem Werkzeug gute und schlechte Ergebnisse erstellen kann, also dass Werkzeuge und deren Verwendung oder Nichtverwendung in irgendeinen Verhältnis zur Qualität stehen würden.
dedlfix.
Man kann genauso gut lesbaren wie unlesbaren, guten wie schlechten, schnellen wie langsamen Code mit und ohne TE erstellen. Eine TE allein bringt noch keine Verbesserung ins Team, wenn das Team nicht von sich aus bereits Qualität liefern kann.
Wahrscheinlich hast noch noch nie ein Framework in C entwickelt, sonst würdest Du solche Sprüche nicht gebetsmühlenartig und in Folge herunterleiern.
Man kann genauso gut lesbaren wie unlesbaren, guten wie schlechten, schnellen wie langsamen, sicheren oder unsicheren, sogar funktionierenden oder nicht funktionierenden Code in C oder einer anderen Programmiersprache erstellen.