xtc(M): Sinn oder Unsinn von Smarty

[jumpmore]

Hallo alle zusammen,
ich frage mich wieder einmal, warum bei xtc (und anderen Systemen) Smarty benutzt wird.

Hintergrund:
ich werde mit Smarty und vorallem mit den vielen benötigten html-Dateien nicht wirklich warm.
Vielleicht liegt es daran, dass ich PHP- und WordPress-verwöhnt bin und die Möglichkeiten (RSS-Feeds, URL-freundliche Domainadressen auch ohne modified-Datei, API), die mir beide bieten im Laufe der Zeit schätzen gelernt habe.
Deswegen würde ich gerne Smarty und die html-Dateien peu a peu durch php-Dateien ersetzen wollen.
Ist dies möglich oder gibt es für die Verwendung von Smarty in xt:Commerce einen wichtigen Grund, den ich bislang noch nicht entdeckt habe?

Sollte die Nutzung von Smarty nicht unbedingt erforderlich sein, dann würde ich diese gerne dahingehend ändern und auf Wunsch auch diese anderen gerne zur Verfügung stellen.

Vielen Dank im Voraus für eure Antworten.

VG Elke



Linkback: https://www.modified-shop.org/forum/index.php?topic=12011.0

[DokuMan]

Hallo Elke,

Ich denke der ursprüngliche Gedanke von Smarty war die einfache Austauschbarkeit von Templates, sowie Caching.
Der Grund, warum es alle xtc-forks enthalten, ist sicherlich historischer Natur.

Denn Sinn des bloßen Ersetzens von html-Dateien durch PHP-Dateien habe ich jetzt nicht verstanden. Der Rattenschwanz an Dateien bleibt ja dann trotzdem.

Viele Grüße
Simon

[hendrik]

[...] dass ich PHP- und WordPress-verwöhnt bin [...]

Der Templategenerator trennt Design und Logik voneinander. Es schafft die Möglichkeit von Arbeits- und Aufgabentrennung. Daß auch Menschen ein Template erstellen und Pflegen können die keine Codercracks sind und nicht in Einsen und Nullen denken. Und für die Coder und Shopentwickler ist es ne Entlastung. Wenn das Outfit einer Software die vielfältig eingesetzt wird und stets individualisiert werden muß abgetrennt ist kann die Entwicklung der Logik unabhängig verlaufen. Die Coder kümmern sich um die Datenverarbeitung, die Designer ums Design.

Was du propagierst war früher mal. Findest du im im Museum. http://www.oscommerce.com/
Damals musste man eingefleischter PHP-Progger sein um ein Template (um-)bauen zu können. Und da Coder selten auch gleichzeitig gute Designer sind sahen die Templates entsprechend aus. Ebenso gab es viele Templates: Fast keine, und diese sahen auch irgendwie alle gleich aus.

Das mag für dich vielleicht nicht zutreffen. Mag sein du liest Programmcode wie die Morgenzeitung. Und PHP, HTML, CSS in einer Soße ist für dich genau die richtige Mischung. Allerdings unter ökonomischen Gesichtspunkten hat sich der Ansatz der Trennung als effektiver erwiesen.

Hat mich früher auch verwirrt. Wenn man sich aber mal mit einem Templategenerator vertraut gemacht hat und die Denke eine Stufe angehoben hat (PHP->Output zu PHP->Template->Output) lernt man die Vorteile zu schätzen. Spart auch ne Menge Arbeit wenn man sich nicht für jeden Kleinkram durch den Programmcode wühlen muß.

Gruß
Hen

[Matt]

Wobei man zwei Sachen beachten muss: Das von hendrik im ersten Absatz geschilderte ist die Idealvorstellung. Gerade xt:Commerce weicht davon mitunter extrem ab und verwurstet Code, der eigentlich ins Template gehört, in die php- oder Sprachdateien...

Und das es so viele Dateien gibt ist historisch bedingt. Man könnte das, auch mit Smarty, auch mit deutlich weniger Files realisieren. Was man vom Entwickler-Standpunkt aus auf keinen Fall will ist die "Lösung", wie sie in Wordpress umgesetzt ist.

[hendrik]

Allerdings. Da hast du Recht. Das Smarty-Templatesystem ist zwar ein Riesenvorteil gegenüber osCommerce. Aber alles andere als der Weisheit letzter Schluß.

Gruß
Hen

[jumpmore]

Zunächst einmal:
Vielen Dank für eure Beiträge.

@Mat und an alle anderen:

[...] Was man vom Entwickler-Standpunkt aus auf keinen Fall will ist die "Lösung", wie sie in Wordpress umgesetzt ist.

Aber warum?
Was ist an der Programmierweise von WordPress so schlecht?
Schließlich bietet es einem viele Möglichkeiten, die in xt:Commerce nicht oder nur mittels Änderungen in vielen verschiedenen Dateien möglich ist.

[...]
Was du propagierst war früher mal. Findest du im im Museum. http://www.oscommerce.com/
Damals musste man eingefleischter PHP-Progger sein um ein Template (um-)bauen zu können. Und da Coder selten auch gleichzeitig gute Designer sind sahen die Templates entsprechend aus. Ebenso gab es viele Templates: Fast keine, und diese sahen auch irgendwie alle gleich aus.
[...]

Da ich wahrscheinlich wie viele andere auch nicht nur Designer, sondern auch Programmierer bin, muss ich in diesem Fall nicht nur ein eingefleischter PHP-Progger, sondern auch ein eingefleischter Smarty-Versteher sein. Und genau das macht für mich keinen Sinn...

Und:
Wenn ich das richtig verstanden habe:
PHP ist eine Template-Engine und Smarty auch, das aber PHP benötigt.
Für mich klingt das nach doppelt-gemoppelt und deswegen ziemlich unsinnig, vorausgesetzt es gibt nicht den oder die Vorteile, die mir im Moment nicht bekannt sind.
Denn auch mit PHP und MySQL-Datenbanken kann ich problemlos Design und Daten voneinander trennen. D.h. dafür benötige ich nicht zusätzlich Smarty und komme deswegen zu meiner Eingangsfrage zurück:

[...] gibt es für die Verwendung von Smarty in xt:Commerce einen wichtigen Grund, den ich bislang noch nicht entdeckt habe?

VG Elke

P.S. Leider musste ich wieder mit dem Absenden noch ungefähr 30 Minuten warten...

[jumpmore]

[...]
Ich denke der ursprüngliche Gedanke von Smarty war die einfache Austauschbarkeit von Templates, sowie Caching.
Der Grund, warum es alle xtc-forks enthalten, ist sicherlich historischer Natur.

Denn Sinn des bloßen Ersetzens von html-Dateien durch PHP-Dateien habe ich jetzt nicht verstanden. Der Rattenschwanz an Dateien bleibt ja dann trotzdem.
[...]

Das bloße Ersetzen von Dateien ist nicht total sinnlos, denn mit Hilfe von PHP kann man z.B. auf die Daten(bank) Einfluss nehmen ohne die Originaldateien gleich ändern zu müssen. Allerdings würde ich bei einer Umstellung auf PHP diese Dateien zusammenfassen und/oder anders gestalten, damit ich wie z.B. bei WordPress diese möglichst vielfältig einsetzen kann.

Was den Cache betrifft:
M.E. kann man dies auch nur mit Hilfe von PHP realisieren oder?

Und wenn das Ganze nur noch historische Gründe hat?
Früher hatten wir auch einmal einen Kaiser,...

VG Elke

[mantis]

@Elke

Du schlägst mit deinen Eigenen Waffen wild auf dich selber ein

Gerade dein Beispiel Wordpress ist überladen da es genau für Leute gemacht ist die nicht selber Programmieren wollen oder können ABER was haben die gemacht ein pseudo Modularen Aufbau mit vielen Eigenen Tags die ähnliches Bewirken wie Smarty.

Ja es gibt einen (sogar mehrere Gründe) Smarty integriert zu lassen
1. Nehmen wir Smarty weg haben wir wieder ein osCommerce (modified)
2. Die Vorteile liegen auf der Hand ein NOOB kann mit etwas HTML und CSS einen ansprechenden Shop gestalten
3. die Overheads von Smarty sind wesentlich geringer als die eines Prop Systems bzw. der meisten anderen Arten zu cachen etc.
4. Du willst eine reine php Lösung - ok schau dir mal an was mit den meisten passiert die das Umsetzen XOOPS, etc. updates usw. sind noch schlimmer als mit xtc
5. Zeig mir ein echtes Modulares Shopsystem welches funktioniert, die Vielfalt an Erweiterungen hat sicher ist etc. --> genau es gibt keines
6. Sollte modified eCommerce Shopsoftware sich ändern wird es wahrscheinlich in richtung Java gehen da dort Sicherheitstechnisch besser programmiert werden kann, echtes Ajax umgesetzt werden kann und viele Design Technische Probleme programatisch gelöst werden können, der Hacken die Ansprüche etwas zu Ändern sind wesentlich höher, die Server Anforderungen sind andere wir leben nun mal in einer Welt wo php und MySql sich für den alltag Durchgesetzt hat, was nicht heisst das es die Ideallösung ist es ist einfach die beste mit den Mitteln die den meisten zur Verfügung stehen.

Nur meine Meinung jetzt darfst du schlagen

Gruss
mantis

[hendrik]

[...]
Denn auch mit PHP und MySQL-Datenbanken kann ich problemlos Design und Daten voneinander trennen. D.h. dafür benötige ich nicht zusätzlich Smarty und komme deswegen zu meiner Eingangsfrage zurück:

[...] gibt es für die Verwendung von Smarty in xt:Commerce einen wichtigen Grund, den ich bislang noch nicht entdeckt habe?

[...]

Kannst du durchaus. Du entwirfst dann dein eigenes System Templates zu realisieren. Im Grunde hast du dann deinen eigenen Templategenerator. So wurde auch Smarty entwickelt. Die Ur-Entwickler wollten Templates und schrieben sich etwas. Das wurde immer weiter verbessert bis eine eigenständige Engine entstand. Nur, daß Smarty-Templates nicht durchsetzt sind mit php-Abschnitten(<?php xxxx ?>) sondern eigene Variablen mit eigener Syntax verwendet. Es ist eine Biblothek, ein Baukasten mit vielfältigen Funktionen.

Die Smarty-Syntax hat selbst Eigenschaften einer Programmiersprache. Aber durch Smarty bleibt die Komplexität der PHP-Programmiersprache außen vor. Ein Templatedesigner muß lediglich wenige marginale Befehle und Konstrukte lernen um ein Smarty-Template erstellen zu können.

Die Problemstellung für eine freie Software wie einen Webshop besteht nicht allein darin, daß es einfach nur funktioniert. Egal wie. Es muß auch übersichtlich sein, wartungsfreundlich, dokumentiert und erweiterbar. Eine Software die nur von eingefleischten Cracks beherrscht werden kann wird schwer den Massenmarkt erobern. Deshalb, und das sagte ich bereits, ist es ein Vorteil, wenn Leute das Template pflegen können die in Ihrem Leben noch was anderes zu tun haben als Codezeilen zu hacken und vor gar nichts Angst haben.

Gruß
Hen

[jumpmore]

Hallo Mantis,

da ich Gewalt grundsätzlich ablehne, werde ich weder auf andere schießen oder andere schlagen, aber ein Spässeken zwischendurch darf wohl auch hier erlaubt sein, oder?

Aber im Ernst:
Ich weiß nicht, ob ich Smarty total ausschließen will. Ich will herausfinden, welche Gründe für Smarty und die derzeitige Struktur vorliegen, um dann mich für das eine oder andere oder auch für beides entscheiden zu können.

[...]
1. Nehmen wir Smarty weg haben wir wieder ein osCommerce Shop (modified)
[...]

Die Info irritiert mich jetzt, denn m.E. sah osCommerce vor ungefähr 3 Jahren ähnlich aus wie xt:Commerce. Hat sich das wirklich geändert?

[...]
3. die Overheads von Smarty sind wesentlich geringer als die eines Prop Systems bzw. der meisten anderen Arten zu cachen etc.
[...]

Das verstehe ich nicht wirklich. Deswegen wäre ich über einpaar klärende Worte dankbar.

[...]
5. Zeig mir ein echtes Modulares Shopsystem welches funktioniert, die Vielfalt an Erweiterungen hat sicher ist etc. --> genau es gibt keines
[...]

Das mag sein, aber d.h. ja nicht das man ein solches System nicht verbessern kann/sollte.

[...]
6. Sollte modified eCommerce Shopsoftware sich ändern wird es wahrscheinlich in richtung Java gehen da dort Sicherheitstechnisch besser programmiert werden kann, echtes Ajax umgesetzt werden kann und viele Design Technische Probleme programatisch gelöst werden können, der Hacken die Ansprüche etwas zu Ändern sind wesentlich höher, die Server Anforderungen sind andere wir leben nun mal in einer Welt wo php und MySql sich für den alltag Durchgesetzt hat, was nicht heisst das es die Ideallösung ist es ist einfach die beste mit den Mitteln die den meisten zur Verfügung stehen.
[...]

Selbst wenn es eine Ideallösung geben würde, wird man im Laufe der Zeit immer mal wieder feststellen, dass diese geändert werden muss, weil sich bestimmte Dinge (technischnische und andere Möglichkeiten) im Laufe der Zeit sich geändert haben.
D.h. z.B. das was gestern noch ein Muss (Platz, Geschwindigkeit,...) war, ist heute oder morgen keine Diskussion mehr wert.

Nichts für ungut.
Ich will ja nur herausfinden, was hinter Smarty & Co. steckt.


VG Elke

[jumpmore]

[...] Ein Templatedesigner muß lediglich wenige marginale Befehle und Konstrukte lernen um ein Smarty-Template erstellen zu können.
[...]

Gibt es irgendwo eine Liste dieser Befehle und Konstrukte, die xt:Commerce verwendet?

[...]
Die Problemstellung für eine freie Software wie einen Webshop besteht nicht allein darin, daß es einfach nur funktioniert. Egal wie. Es muß auch übersichtlich sein, wartungsfreundlich, dokumentiert und erweiterbar. Eine Software die nur von eingefleischten Cracks beherrscht werden kann wird schwer den Massenmarkt erobern. Deshalb, und das sagte ich bereits, ist es ein Vorteil, wenn Leute das Template pflegen können die in Ihrem Leben noch was anderes zu tun haben als Codezeilen zu hacken und vor gar nichts Angst haben.
[...]

Da xt:Commerce keine API hat, müssen normalerweise die Originaldateien geändert werden. Das hat zur Folge, dass die Wartungsfreundlichkeit (Updates) auf 0 sinkt.
Wie bereits gesagt:
Für Leute, die sich so wie ich damit noch nicht so gut auskennen, sind es wahnsinnig viele Dateien, die für die Anzeige einer Seite benötigt werden und in diversen Ordner rumschwirren. Wenn ich ganz ehrlich bin, verstehe ich unter Übersichtlichkeit etwas anderes. Bleibt also (für mich) die Dokumentation.
Übrigens: WordPress hat den Massenmarkt erobert und auch da gibt es viele, die keine oder nur wenig Ahnung von PHP haben. Brauchen sie auch nicht, weil viele Einstellungen/Änderungen über Plugins und das Admincenter erfolgen.

VG Elke

[Matt]

[...]
Was ist an der Programmierweise von WordPress so schlecht?
Schließlich bietet es einem viele Möglichkeiten, die in xt:Commerce nicht oder nur mittels Änderungen in vielen verschiedenen Dateien möglich ist.
[...]

Es ist unglaublich unübersichtlich. Und kein mir bekannter Editor kann vernünftig mit diesem Mischmasch umgehen, sei es in Bezug auf Code Highlighting oder Code Folding. Damit wird das arbeiten in diesen Dateien zur Qual.

[...]
Wenn ich das richtig verstanden habe:
PHP ist eine Template-Engine und Smarty auch, das aber PHP benötigt.
[...]

Das hast du falsch verstanden. PHP ist keine Template-Engine. Smarty schon.

[...]
Denn auch mit PHP und MySQL-Datenbanken kann ich problemlos Design und Daten voneinander trennen. [...]

Ja, aber du kannst die Anwendungslogik nicht von der Präsentationslogik trennen. Zumal man Inhalte in einer Datenbank medienneutral speichern sollte.

Das bloße Ersetzen von Dateien ist nicht total sinnlos, denn mit Hilfe von PHP kann man z.B. auf die Daten(bank) Einfluss nehmen ohne die Originaldateien gleich ändern zu müssen. [...]

Du wünscht dir ein vernünftiges, modulares Plugin-Konzept. Das ist was ganz was anderes.

[...]
M.E. kann man dies auch nur mit Hilfe von PHP realisieren oder?
[...]

Man kann natürlich auch opcode caching auf Serverebene machen oder sich was mit memcached basteln. Oder eben selber bauen (siehe die unzähligen Cachinglösungen für Wordpress). Ich stelle leider immer wieder fest, dass man in PHP lieber das Rad zehn mal neu erfindet anstatt auf bewährte Lösungen zu setzen. Anders ist es auch nicht zu erklären, warum das PEAR im Vergleich etwa zum CPAN so ein Schattendasein in der PHP-Welt fristet. Nur - wie willst du die kritische Masse erreichen wenn eine deiner Installationsvoraussetzungen 'Server mit root-Zugriff' ist?

[...]
Die Info irritiert mich jetzt, denn m.E. sah osCommerce vor ungefähr 3 Jahren ähnlich aus wie xt:Commerce. Hat sich das wirklich geändert?
[...]

Nein, definitiv nicht. osCommerce hat bis heute keine Template-Engine am Start und wird das auch in der nächsten Version nicht haben. Und wenn ich das sehe was osCommerce als Templates verkauft wird mir immer schlecht.

[...]
Da xt:Commerce keine API hat, müssen normalerweise die Originaldateien geändert werden. [...]

Du wünscht dir ein vernünftiges, modulares Plugin-Konzept (sagte ich das nicht schon?). Das ist was ganz was anderes.

[...] Wenn ich ganz ehrlich bin, verstehe ich unter Übersichtlichkeit etwas anderes. [...]

Dann schau dir besser nicht Magento an.

[...]
Übrigens: WordPress hat den Massenmarkt erobert und auch da gibt es viele, die keine oder nur wenig Ahnung von PHP haben. [...]

Ja, Wordpress hat den Massenmarkt erobert. Das heißt nicht, dass das, was Wordpress macht, das Nonplusultra ist.

[...] Brauchen sie auch nicht, weil viele Einstellungen/Änderungen über Plugins und das Admincenter erfolgen.
[...]

Du wünscht dir ein vernünftiges, modulares Plugin-Konzept. Das ist vollkommen unabhängig von der Verwendung einer Template-Engine realisierbar. Nur nicht für xt:Commerce. Da ist meiner Meinung nach der Zug vor viel zu langer Zeit schon abgefahren.

[speedy]

Wordpress zeigt sehr schön, dass das was man sieht wichtiger ist, als das was man nicht sieht.
Programmierer sehen das ja oft gerne umgekehrt.
Wobei ich sagen muss, dass mir das Plugin-System von Wordpress sehr gut gefällt - Installationen / Updates gingen nicht leichter und schneller. Auch Updates von Wordpress selbst.

[Matt]

Aber auch die Updatefähigkeit und vor allem -einfacheit bei Wordpress ist etwas, das es nicht in die Wege gelegt bekommen hat. Es war ein langer und steiniger Weg bis dahin.

[jumpmore]

Hallo Matt,

ja, ich will...
...eine Api, die es mir ermöglicht schnell und unkompliziert Funktionen hinzuzufügen bzw. zu ändern.
...Template-Dateien, die ich schnell und unkompliziert so gestalten kann
ohne...
...die Originaldateien ändern zu müssen, auch damit ein Update auf das System nicht 200 Stunden dauern muss.

Allerdings frage ich mich, warum das nicht mehr erreichbar sein soll?
Man, z.B. ich, muss nur einfach mal anfangen, wobei das Ganze natürlich nur Sinn macht, wenn diese Änderungen (z.B. für die Api) dann auch in die Originaldateien übernommen und allen zur Verfügung gestellt werden. Wenn nicht, dann habe ich das Problem mit dem Update auch noch nach den Änderungen. Und dann ist fraglich, ob sich der Aufwand tatsächlich lohnt.

Vor einiger Zeit habe ich damit begonnen eine Api für xt:Commerce zu erstellen, habe dann aber nachdem meine Bedürfnisse halbwegs befriedigt waren auch aus Zeitgründen damit wieder aufgehört.
Inzwischen habe ich neue Erkenntnisse erworben, sodass sich einige Dinge, die ich damals programmiert habe, sich auch erübrigt haben.
Aber der Wunsch ist nach wie vor da, so etwas zu integrieren, aber auch deswegen, um den Austausch zwischen WordPress und xt:Commerce bzw. modified eCommerce Shopsoftware zu erleichtern.

Aber wie gesagt, ob sich der Aufwand für nur einen Shop wirklich lohnt, ist fraglich.

Und:
Wenn ich dann zum Schluss feststelle, dass für das Template Smarty tatsächlich ein Muss ist, dann fände ich das nicht gerade erheiternd, denn ich arbeite nur sehr ungerne für die Mülltonne.

Deswegen auch meine Frage:

[...] gibt es für die Verwendung von Smarty in xt:Commerce einen wichtigen Grund, den ich bislang noch nicht entdeckt habe?

VG Elke