xtc(M): Sinn oder Unsinn von Smarty

[Matt]

[...]
...eine Api, die es mir ermöglicht schnell und unkompliziert Funktionen hinzuzufügen bzw. zu ändern.
[...]

Du willst ein Modulsystem. Könnten wir uns darauf einigen, dass wir nicht von einer API reden? Du willst nämlich keine Schnittstelle, die es dir ermöglicht, mit Drittprogrammen mit deinem Shop zu interagieren.

[...]
...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.
[...]

Genau das ist doch (gerade wegen Smarty!) jetzt schon möglich. Ich werde das Gefühl nicht los, dass deine Probleme gar keine sind, aber Smarty als Sündenbock herhalten muss.

[...]
Allerdings frage ich mich, warum das nicht mehr erreichbar sein soll?
[...]

Weil für ein vernünftiges Modulsystem xt:Commerce nicht objektorientiert genug ist.

[...]
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.
[...]

Die Anforderungen gehen doch selten darüber hinaus, Inhalte aus dem einen System im anderen darzustellen. Und das kann man von xt:Commerce zu WordPress lösen, indem man sich eine Schnittstelle (API, diesmal wirklich) baut, die die gewünschten Daten aus xt:Commerce zur Verfügung stellt (z.B. korrekte Links) oder, für die umgekehrte Richtung, den RSS-Feed anzapft. Auch mit benutzerdefinierten Feldern in WP kommt man ziemlich weit, ohne hier gleich alles von Grund auf neu überdenken zu müssen und die API kann komplett losgelöst vom eigentlichen Core erstellt werden. Mit Smarty hat das am Ende gar nichts mehr zu tun.

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

Schichtentrennung, saubere, klare Struktur, keine Programmierkenntnisse nötig um Änderungen am Präsentationslayer vornehmen zu können, Caching inklusive. Wobei das alles generelle Punkte sind, die für eine Template-Engine sprechen. Bei xt:Commerce ist es in der Tat so wie Mantis es bereits gesagt hat (und das ist ein wichtiger Punkt, da es so miteinander verwoben ist, das man es mit vertretbarem Aufwand gar nicht mehr auseinander bekommt, da kann man gleich ein neues Shopsystem schreiben): Wenn du es ausbaust hast du osCommerce. Und dann kannst du den auch gleich direkt nehmen.

[jumpmore]

Hallo Matt,

sorry, aber leider haben auch Deine Argumente mich noch nicht von der Nutzung von Smarty(befehlen) überzeugt, auch vor dem Hintergrund, dass die Cache-Funktion aus Sicherheitsgründen nicht oder nur teilweise genutzt werden sollte (siehe: Datensätze von Kunden durcheinander?).

Und was (einen Teil) der von Dir benutzten Begrifflichkeiten betrifft:
1. Eine API ist eine "Schnittstelle für Anwendungsprogramme". Die Nutzung von APIs erlaubt es Softwareentwicklern, Anwendungen zu schreiben und dabei bereits vorhandene, standardisierte Bibliotheksroutinen zu nutzen. (siehe: API - Was bedeutet API?)
...und muss aus diesem Grund nicht unbedingt mit Drittprogrammen in Verbindung gebracht werden.
Des Weiteren: Mit Smarty hat die API tatsächlich nichts zu tun, aber mit dem eigentlichen Core schon, denn ich will ja auch die bereits vorhanden Funktionen nutzen (s.o).

2. Ein Tipp bzgl. Editor, Code Highlighting oder Code Folding:
Notepad++ ist ein kostenloser Editor, der den Nutzern Code Highlighting (Syntaxhervorhebung) von   von bzw. Code Folding (ausblenden von Codebereichen) zur Verfügung stellt.

3. Grob gesprochen ist die Präsentationslogik ein Teil der Anwendungslogik, die wiederum die Aufgabe hat, die vorhandenen Daten (in der Datenbank) aufzubereiten und in diesem Fall den Besuchern der Webseite zur Verfügung zu stellen. Natürlich kann man das eine vom anderen trennen, muss es aber nicht.
...

Wenn ich ganz ehrlich bin, habe ich - nicht nur deswegen (aber auch) - immer mehr den Eindruck, dass xtc für (andere) Programmierer und Designer nicht benutzerfreundlicher gestaltet werden soll. Denn auch hier spielen bei der Preisgestaltung Angebot und Nachfrage eine große Rolle. Und wer lässt sich schon gerne "die Butter vom Brot nehmen"? O.K. die Dummies von WordPress,...
Aber vielleicht ist ja modified eCommerce Shopsoftware der 1. Schritt dieses zu ändern, denn bzgl. der Nutzung des Forums und der Downloads gibt es so gut wie keine Einschränkungen. Und allein das ist schon eine Menge wert.

VG Elke

[jumpmore]

Leider bin ich erst jetzt auf die Webseite von gunnart.de aufmerksam geworden:
In jedem Fall bin ich davon überzeugt, dass ich mit Hilfe der dort angebotenen Funktionen + PHP viele Probleme lösen kann ohne den Quellcode ändern zu müssen.
Und das freut mich natürlich sehr.

Hier einige Links, die ich persönlich wahnsinnig interessant finde und nur zu gerne weiterempfehle:

• Smarty Modifier für xt:Commerce - Mehr Übersicht bei der Template-Programmierung
• Smarty-Function “ContentData” für xt:Commerce
• Smarty-Function “gunnartProductsList” für xt:Commerce
• Smarty-Function “CatNavigator” für xt:Commerce

Nachtrag:
Auch wenn ich den folgenden Tipp bzgl. WordPress + XTC bereits an einer anderen Stelle hier im Forum veröffentlicht habe:

Einen Lösungsansatz wie man XTC und WordPress zusammenbringen kann, findet man auf bueltge.de: WordPress Funktionen außerhalb von WordPress nutzen

Ich hab's mal ausprobiert und am Anfang der Datei includes/application_top.php folgenden Code eingefügt:

Code: PHP  [Auswählen]

if (file_exists('../wp-load.php')) {
    require('../wp-load.php');
}

(ggf. muss der Pfad der Datei wp-load.php noch angepasst werden. In diesem Fall befindet sich der Shop in einem Unterverzeichnis und WordPress im Rootverzeichnis.)

Und:
Anschließend stehen einem die Funktionen von WordPress und damit auch die API von WP (fast) überall zur Verfügung.

VG Elke