ich bin gerade dabei mich ein wenig mit Oxid zu beschäftigen, da ich demnächst einen neuen Shop mit Oxid entwicklen werden. Inzwischen habe ich mir die Modul Entwicklung (eigenes Modul schreiben, ein bestehendes einbinden usw.) und den allgemeinen Aufbau von Oxid (also Klassenstruktur, Einbindung von Klassen usw.) ein wenig angeschaut. Nun bin ich an dem Punkt: Controller Views und Templates.
Die Frage die sich mir nun stellt ist: Soll ich wirklich das bestehendes Template und (M)VC System von Oxid verwenden oder ein anderes nehmen um das Frontend zu verwirklichen?
Den Shop den ich umsetzen muss, wird recht wenig mit dem Basic-Layout von Oxid gemeinsam haben, weshalb ich mir sowie ein komplett neues Layout anlegen muss. Alleine der Hintergrund dass das Standard Template HTML 4 ist und nicht XHTML (Voraussetzung in dem Projekt) führt dazu dass ich alles komplett umschreiben müsste und es somit unbrauchbar ist.
Nachdem ich dann alle Templates wegschmießen kann, kann ich die Views auch vergessen, da diese ja direkt zusammenhängen. Die Views kümmern sich ja schließlich darum, dass die tpl Dateien die Daten bekommen… Nachdem ich nun alle tpl Dateien und alle View Dateien löschen kann bleibt nur noch der Controller übrig.
Ein weiteres Problem ist, dass die kompletten Dateien in htdocs liegen und somit von außen aufrufbar sind, was aber nicht sein darf.
Deshlab meine Idee:
Frontend:
Ich benutze für den Controller und die Views etwas eigenes bzw z.B. ein System von ezc oder ähnliches und binde Oxid, welches außerhalb von htdocs liegen soll, ein. Somit könnte ich auf die Models, also z.B. Warenkorb-Logik zurückgreifen. Dynamische Seiten habe ich nicht, also der Kunde wird keine Customseiten anlegen können. Die Lösung von Oxid das Templates in der Datenbank liegen (Kundeninformation -> CMS Seiten) halte ich für eine Recht bescheidene Lösung und Frage mich warum das alles? Ich will meinen eigenen Editor benutzen und nicht in einer Textarea arbeiten müssen (Code-Highlighting Autocomplete etc.). TPL Dateien emfpinde ich als bessere Lösung und auch hier gibt es includes. Der Kunde wird wie gesagt im Frontend nichts ändern können…
Außerdem habe ich den Vorteil, dass von außen es nicht zu erknnen ist, dass ich Oxid verwende (Keine Dateien wie /out/xxx/src/*.js).
Backend:
Der Kunde bekommt dann eine weitere Grundoxid-Installation. Diese läuft auf der selben DB und ist per HTTP-Auth gesichert. Außerdem ist die URL nur dem Kunden bekannt. Hier kann er dann Produkte etc eintragen.
Nun zu eurer Meinung bzw Erfahrung:
Ist die Idee totaler Quatsch? Wie habt ihr es gemacht?
Warum willst du denn bitte die views wegschmeissen? Das wäre doch nur sinnvoll wenn deine Daten komplett anders wären und nichts mit dem standard zu tun hätten. Das einzige was du wohl oder übel tun musst ist alle templates anpassen - was ist denn daran so schlimm wenn man sehen kann dass es ein oxid ist? Wenn du kein Oxid willst dann nimm doch einfach kein Oxid
Bis jetzt habe ich einfach alle templates ersetzt oder überschrieben und meine eigenen css Daten etc. angelegt.
Die htaccess von Oxid verhindert im übrigen einen direkten Zugriff auf die tpl Dateien und dergleichen, kannst es gerne mal probieren ein template über das web aufzurufen.
Warum auch, die Views sind eigentlich nur getter für Objekte, die man im Template nutzen kann.
Bei den Anforderungen würde ich mir eher Überlegen auf Smarty zu verzichten und eine <böese>richtige Templatengine</böse> zu nutzen.
So bleibt alles bis auf die Templates updatebar und Drittanbietermodule, welche Views erweitern kann man weiterhin nutzen.
Und das die Pfade alle innerhalb der Applikation liegen, dass sollte auch mittels include_path plus einer eigenen __autoload Funktion machbar sein.
… obwohl bis auf Bilder, CSS, Javascipt usw. werden diese ja per htaccess umgeleitet.
Wegen Oxid nicht erkennenbar machen… ich glaube, das wird nicht gerne gesehen, wenn man die Copyright-Notice aus den HTML-Quelltext entfernt.
Mit den CMS-Seiten… also diese ‘bescheidene Lösung’ die Seiten in die DB zu packen machen derzeit eigentlich alle größeren CMS-Systeme. Für alternativen bietet couchDB Ansätze.
Ach ja, ich lese immer was von ‘ich’ und nicht ‘wir’… ist nicht Dein Ernst alles neu machen zu wollen.
Die Views will ich deswegen wegschmeißen, da ich ja auch alle tpl Dateien wegschmeißen werde. Was bringt es mir wenn die View der Startdatei lauter Krams holt, welchen ich auf der Startseite nicht brauche. Den Inhalt des Views muss ich also neu schreiben, das meinte ich mit wegschmeißen… Und es bleibt nicht bei der Startseite sondern es betrifft ja alle Seiten…
Sollte der Apache fehlerhaft laufen könnte es durchaus passieren das die htaccess nicht korrekt eingelesen wird und die Sicherheit damit dahin ist. Klar - recht unwahrscheinlich aber sehr ärgerlich. Die contig.inc.php habe ich direkt ausgelagert und ersetzt mit:
<?php include dirname( FILE ) . ‘/…/config/config.inc.php’;
Nicht auszudenken was passieren würde wenn php-Dateien auf einmal im Klartext ausgegeben werden die Leute wissen es ist Oxid und dann /config.inc.php aufrufen. Klar die DB kann man noch auf die IP beschränken, aber auch das lässt sich leicht umgehen…
Das mit der Updatebarkeit ist natürlich so eine Sachen wenn man die Views alle über den Haufen wirft, da gebe ich dir 100%ig recht. Kommt drauf an wieviele fremde Erweiterungen man einbindet und wenn man eh alles über den Haufen wirft ob man dann Erweiterungen die die Views betreffen bruacht / benutzen kann…
Was meinst du mit böser Templateenginge? PHP? Also alles direkt in den Views reinschreiben / ausgeben?
Mit “ich” meine ich auch “wir”, das ist wohl der menschliche ego-Trieb, also es entwicklen schon ein paar Leute mit… Wegen dem Copyright: Wir werden die PE Version benutzen, mal schauen wie es dann damit aussieht, ich weiß es nicht…
Also die Views haben get-Methoden, welche den Templates Objekte zur Verfügung stellen.
zB:
start::getArticleList();
Derzeit wird diese Liste noch in start::render() wegen Abwärtskompatibilität direkt geladen… zukünftig soll dies aber (hoffentlich) nur noch Template geschehen.
[{assign var=“oArticleList” value=$oView->getArticleList()}]
Oder anders ausgedrückt, ein Modul schreiben, welches dieses preloading in der render-methode nicht macht und Du hast wieder (fast) die beste Performance.
Dann abwarten, bis ein update diese Kompatibilität aufgibt und das Modul wegschmeißen.
Das ‘böse’ waren Tags - ich mag Smarty nicht und würde für so etwas eine andere Engine nehmen… zB. https://projects.oxidforge.org/projects/killsmarty
Und das ganze weil Smarty mit Objekten einfach ein Krampf ist.
Und wie schon geschrieben… mittels __autoload bzw. include_path sollte man (mit ein wenig fummeln) alles auslagern können.
- ich mag Smarty nicht und würde für so etwas eine andere Engine nehmen… zB.