So geht das nicht!

Wenn ich mir die ansehe, wie viele Änderungen bei der Version 4.2.0 an den Template-Dateien vorgenommen wurden, verliert man schon irgendwie die Lust, OXID-Templates zu machen, die auch nur [B]minimal [/B]vom Standard-Template abweichen!

Leider geht die OXID AG da m.E. [B]maximal rücksichtslos [/B]vor!

[B]Es geht einfach nicht[/B], dass man bei jedem Update [B]jede [/B]Template-Datei [B]manuell[/B] auf mögliche Änderungen prüfen muss, [B]wer soll das denn pflegen[/B]?

(Und da sind nicht nur Template-Entwickler betroffen, sondern auch Shop-Betreiber, die ihrem Shop wenigstens [B]ein wenig [/B]ein anderes Gesicht geben wollen, oder auch mal ein Javascript (oder was immer auch) einbauen wollen.)

Im aktuellen 4.2.0 Update gibt es ca. [B]60[/B] (in Worten [B]sechzig[/B]) Dateien, die im Frontend-Template geändert wurden.

Mit so “wichtigen” Änderungen wie:

statt z.B. “$oView->getWishList()” muss nun “$oView->getWishListUsers()” verwendet werden, oder: die “DETAILS_PERSPARAM_XXXXXXXX”-Sprachkonstanten heissen nun nur noch “DETAILS_XXXXXXXX”.

Es reicht [B]definitiv[/B] nicht aus, dass die OXID-Entwickler nur das OXID-Standard-Template im Auge haben, sondern es muss bei [B]jeder [/B]Änderung im Template-Code bedacht werden, was für einen [B]Rattenschwanz an Aufwand [/B]das bei den Shop-Betreibern hervorruft.

Das ist der [B]große Nachteil [/B]des Konzepts, wie in OXID Smarty verwendet wird: hier werden nämlich die darzustellenden Daten erst im Template ermittelt, aus Methoden und Eigenschaften der vorhandenen Objekte.

Bei xtCommerce z.B. werden hingegen die [B]schon ausgewerteten Daten [/B]übergeben, und da ist es dem Template völlig egal, ob die Shop-Software dazu intern “$oView->getWishList()” oder "$oView->getWishListUsers() verwenden muss, um diese Daten zu erstellen, es merkt von solchen Änderungen der Internals absolut nix…

[B]Bei OXID schlagen solche internen Interface-Änderungen aber [COLOR=Blue]voll in das Template durch![/B][/COLOR]

Deshalb ist es [B]absolut notwendig[/B], dass die OXID-Entwickler hier möglichst die Finger von solchen (kosmetischen) Änderungen lassen, und/oder die [B]Rückwärtskompatibilität[/B] sicher stellen!

Das ist ein echter “Schocker” am frühen Morgen…

ach was…

Es geht hier doch um Technik und nicht um Shopbetreiber mit Geschäft :wink:

Ich kann Avenger nur beipflichten, jetzt hab ich den Shop soweit fertig machen lassen und darf jetzt wieder in die Tasche greifen weil das Template wieder überarbeitet werden muss! Und erzählt mir nichts von das ging nicht anders und bla bla bla… ich kann mit word immer noch Dokumente öffnen die ich vor 5Jahren und länger geschrieben habe!

Ich habe auch Alpträume bekommen… und wenn ich mir vorstelle, dass ein neues Template-Modell ganz oben in der Wunschliste steht.:eek:

Währe es nicht besser solche Sachen per Smarty-Plugin wie bei den Multilang-Geschichten zu lösen?
Oder halt ein wenig mehr Logik in die View reinzupacken?

Das sind ganz simple Funktionen, die unter copy_this fallen.

Hi,

bin auch etwas überrascht, auch wenn derzeit noch das Standardtemplate verwendet wird, da für OXID das neue Template erst in Planung ist. Zwar finde ich das neue Feature des Custom Templates schon klasse, aber irgendwie sollte man zukünftig die Spanne zwischen Kosmetik und Notwendigkeit etwas genauer beachten. Dass auf Grund der neuen Features eine Anpassung der details.tpl etc. notwendig wurde, ist klar und nachvollziehbar. Aber wie Avanger schon schrieb sind andere Dinge einfache Kosemtik und ziehen bei einem vom Standard abweichenden Template immense Arbeit nach sich.

Jap ich kann Avenger hier nur beipflichten, die Änderungen waren schon etwas heftig … zum Glück musste ich nur ein TPL ändern, Rest war ja farblich alles in der CSS.

Problem ist nur, wenn man einige TPL Varianten anbietet, dann ist man ganz schnell am Arsch … vorallem Kunden die erst ein TPL gekauft haben, haben dann meist gleich die richtige A Karte, oder die etwas außerhalb der Karenzzeit liegen, da hat man dann immer gleich blutige Ohren …

Vote me:
http://oxid.uservoice.com/pages/31940-feature-requests/suggestions/368454-use-the-template-override-system

Hier ist ein Vorschlag von mir, in deutsch und klartext meine ich,
dass das Basistemplate nur für die Funktionalität da sein sollte. Kosmetik soll dann in sCustomTheme ausgelagert werden. So sollten die Folgenden Updates ein wenig übersichtlicher sein.

volle zustimmung!

meines erachtens ist aber auch die frequenz der updates mittlerweile unzumutbar. wir betreiben 5 shops, die jeweils unterschiedlich mit etlichen modulen und anpassungen verändert wurden, ich kann bald jemand einstellen der nur die mit den updates zusammenhängenden arbeiten macht.

13 versionen in gut 10 monaten, das ist echt ätzend!
zumindest updates mit templateänderungen sollten deutlich reduziert werden.

Auch ich finde die Anpassungen an den Tempaltes nicht wirklich toll. Der Aufwand, insbesonders auch der Testaufwand wird doch massiv höher sein, als bei den bisherigen Updates.Als Ergebnis hat man jedoch wieder einige Funktionen, welche doch von einem grossen Anteil der Shopbesitzer genutzt werden können.
Betreffend der Update-Frequenz. Es sollte berücksichtigt werden, dass Templateänderungen nur in den Major Releases gemacht werden müssen. Das waren bisher zwei. Aus meiner Sicht sollte jedoch auch die Frequenz der Minor Releases überdenkt werden. Da kamen doch einige Updates auf die Shopbetrieber zu. Man sollte sich jedoch immer bewusst sein, dass diese hohe Frequenz auch Vorteile hat. Schliesslich schreien einige Benutzer jeweils nach Bugfixes, was dann eben zu einer hohen Anzahl von Updates führt. Versorgt Oxid uns während längerer Zeit nicht mit den Lösungen, ist es auch wieder nicht recht.

Dem kann ich ebenfalls nur zustimmen. Ich habe mir angewöhnt, nach Erscheinen eines Updates immer ein paar Tage abzuwarten, welche Bugs so in der Community mit dem Update autauchen und habe mir das Update daher noch nicht im Detail angesehen.

Habe aber schon jetzt keine große Lust mehr, wieder alle notwendigen Daten umzustricken. Um den Shop “up-to-date” halten zu wollen, wird mir aber wohl - wieder mal - nichts anderes übrig bleiben.

Oxid tät wirklich gut daran, die Templates irgendwie vom Programmcode zu trennen.

Gruß

[QUOTE=fragarena;17257]Oxid tät wirklich gut daran, die Templates irgendwie vom Programmcode zu trennen.[/QUOTE]
Das ist ja der Sinn eines Templates…

[QUOTE=fragarena;17257]
Oxid tät wirklich gut daran, die Templates irgendwie vom Programmcode zu trennen.
[/QUOTE]

Verstehe ich nun nicht ganz. Mit dem Templatesystem hast du den Programmcode doch getrennt.

[QUOTE=roland76;17260]Verstehe ich nun nicht ganz. Mit dem Templatesystem hast du den Programmcode doch getrennt.[/QUOTE]
Nein, in dieser Implementierung eben nicht!

Wenn sich der Name einer Objekt-Methode z.B. von “$oView->getWishList()” zu “$oView->getWishListUsers()” ändert, darf das bei einem Template keine Auswirkungen haben!

Derzeit schlagen alle solche Änderungen dieser Shop-Interna aber voll in das Template durch.

Betreffend der Update-Frequenz. Es sollte berücksichtigt werden, dass Templateänderungen nur in den Major Releases gemacht werden müssen

Soweit ich weiss ist genau das so ab jetzt umgesetzt.

Wollte ich eigentlich auch so ausdrücken. Eventuell aber zu unverständlich. :slight_smile:
Nach meinem Wissen waren in den Minor Release bisher nie Updates in den Tempaltes notwendig.

[QUOTE=csimon;17262]Soweit ich weiss ist genau das so ab jetzt umgesetzt.[/QUOTE]
Warum will mich das nicht so recht beruhigen?

Wenn ich viele Kunden mit meinen Templates beglücke, dann ist so ein Update, bei dem 60 Dateien für jeden Kunden händisch angepasst werden müssen eine völlig unnötige, sinnlose und unproduktive Arbeit. (Eine Idiotenarbeit noch dazu.)

Da ist der Ärger mit meinen Kunden vorprogrammiert, die sich auch sehr bedanken werden, dafür wieder zahlen zu sollen.

Bei neuen Featuren ist das ja noch irgendwie verständlich sein, dass man da anpassen muss, aber was ich so auf die schnelle in der Template-Doku gesehen habe gibt es viel zu viele Dinge, die absolut nicht notwendig wären.

Da werden Methoden und Sprachkonstanten umbenannt, Tippfehler in CSS-Klassen korrigiert u.ä.

Sicher gut gemeint, aber niemand hat dabei bedacht, was das “im Feld” für Probleme bereitet.

Nein. Vor 4.1 waren auch schonmal solche änderungen in Minor versionen drin, das war dann ziemlicher aufwand. Mittlerweile hat man das geändert.

Ich finds OK wenn solche änderungen in Major versionen kommen, und man auch gut vorgewarnt wird. Vielleicht sollte man auch sagen, das man diverse Methoden einfach als “deprecated” markiert (veraltet) sie aber trotzdem drin lässt und auf die neuen Funktionen mappt. mit dem nächsten major fliegen sie dann entgültig.

OXID ist übrigens eigentlich schon recht kulant bei Rückwärtskompabilität, es sind noch einige sachen im shop enthalten die nur da sind damit “alte” PE templates noch laufen. Das ist auch für die Betreiber ganz gut so.

Bei neuen Featuren ist das ja noch irgendwie verständlich sein, dass man da anpassen muss, aber was ich so auf die schnelle in der Template-Doku gesehen habe gibt es viel zu viele Dinge, die absolut nicht notwendig wären.

Bei details persparam hab ich einfach search & replace gemacht, genauso bei der wishlist. Das sind noch recht moderate änderungen. Und Multi Varianten ist halt ein neues feature, da isses verständlich das es da ein wenig mehr integrationsaufwand bedarf.

Das man da als Shopbetreiber wenig erbaut ist, versteh ich allerdings auch. Vielleicht sollte man einfach sagen, das man trotz 4.2 den 4.1er zweig noch weiterpflegt wie es u.a. auch die Firefox entwickler machen. Das läuft da teilweise ja sogar Jahre so. Das muss jetzt bei oxid nicht sein, aber so ein halbes jahr würde ich so einer unterversion dann doch noch spendieren.

Stetige Updates sind gut und wünschenswert, das braucht man nicht zu verdammen denn andersrum wär’s auch wieder nicht recht. Aber die Update-Systematik und die Trennung Template -> Code sollte doch nochmal überdacht werden. Es kan nicht schaden sich vor solchen Updates auch mal in den Kunden - den Shopbetreiber reinzuversetzen.

Ich lasse mir gerade ein Templates für OXID machen und eine halbe Woche vor Fertigstellung kommt jetzt diese neue Version. Während ich in den letzten Minors die Updates noch selbst machen konnte (m.E. ist das ein riesen Verkaufsargument für die OXID-Software!) stehe ich nun blöd da, jetzt muss für jedes Update der Entwickler entlohnt werden der, wie Avenger schon schreibt, seine teuer bezahlte Zeit mit Pippifax-Änderungen vergeudet.

Zweigt nach Möglichkeit noch etwas Manpower ab um diese Trennung besser zu machen. Seit ich OXID benutze fällt mir auf dass Templating da bei weitem nicht so verbreitet ist wie bei den bekannten anderen Shops, das mag nicht zuletzt daran liegen wobei es auch gleich eine wichtige Eigenschaft ist, um (s)eine Shopsoftware schnell & effektiv im Volk zu verbreiten…

Viele Grüße,
Martin

Man man, ich auch geschluckt als ich das gesehen habe. Zum Glück sind wir noch nicht live. :-/

In der Tat, jetzt muss man fast jedes Template File durchsehen/durchgehen. Schock hin oder her.

Also eine striktere Trennung zwischen Layout und Logik halte ich nicht für so gut:
[ul]
[li]Lazy-Loading währe dann nicht mehr so einfach/gut möglich, da dies direkt auf das DB-Modell geht… also noch vor der eigentlichen Logik.
[/li][li]Einige Methoden werden teilweise nicht/selten benutzt. Wenn man diese aus der View aufruft, um die Werte im Template direkt zur Verfügung zu stellen, dann sind das Performanceeinbußen.
[/li]Sämtliche Schleifen müssten dann zweimal (doppelt so oft) durchlaufen werden. Eimal in der View zum generieren und einmal in Smarty zum ausgeben… Bei den Kategorien uU. das ganze rekursiv.
Derzeit werden diese vom Template aufgerufen und halt nicht ausgeführt, wenn nicht benötigt. So werden die Schleifn maximal einmal durchlaufen.
Und ob die Updateprobleme im Template oder in der View sind ist gehupst wie gesprungen.
Selbst Smarty möchte in der 3er Version eine bessere Objektunterstützung bieten.
[/ul]

Ich denke auch, dass das Templatekozept von Oxid verbesserungswürdig ist. Aber die Vorteile der Objektorientierung nicht zu nutzen halte ich für den falschen Weg.