Post by CodeSpace » Tue Feb 24, 2015 7:18 pm

Ich finde es wirklich gut, dass es immer mehr deutsche Entwickler gibt. Gibt es denn schon eine gute deutsche Entwickler-Community?

User avatar
Active Member

Posts

Joined
Mon Aug 06, 2012 9:26 pm

Post by IP_CAM » Wed Feb 25, 2015 2:07 am

Du kennst doch wahrscheinlich die deutschsprachige 'Entwickler'-Szene, da vergehen doch nur einige Wochen, und man beschäftigt sich nur noch damit, sich gegenseitig zu diffamieren und runter zu machen. Zumindest früher war es mal so, ich jedenfalls kannte kein einziges deutschsprachiges Forum der Programmiererszene, wo es nicht so war.

Hier auf OC ist es ein Wenig anders, hier scheisst einem bestenfalls der OC Chef Teleboy zusammen, und der versteht ja nicht mal deutsch, hoff ich wenigstens. Wobei ich eigentlich noch Glück habe, als nicht ganz unkritischer OC-Zeitgenosse, aber vielleicht auch nur, weil ich, zumindest im nicht spezifisch 'programmiertechnischen' Bereich, wahrscheinlich schon einigen geholfen habe, und auch sonst hier allgemein nicht ganz unbeliebt zu sein scheine.

Im Weiteren ist es natürlich so, dass Jeder den Anderen wahrscheinlich auch als potentiellen Konkurrenten betrachtet, insbesondere im doch räumlich sehr überschaubaren deutschsprachigen Raum. Und sowas erschwert natürlich die Situation etwas, nehm ich mal an, da doch Jeder seinen Scheiss am Liebsten für sich selber behalten möchte. Zum Glück verstehe ich etwas englisch, da kann ich wenigstens englisch etwas üben. Daher 'mach' ich's noch gern mit Bildern, dann verstehen es wenigstens/hoffentlich auch die, die noch 'untechnischer' englisch schreiben als ich.

Soviel von einem Schweizer, einem, der es 'hirntechnisch' nie dazu brachte, Entwickler zu werden, und sich deshalb darauf beschränkt, 'gesammeltes' Wissen Anderer dazu zu nutzen, um es möglichst sinnvoll und ordentlich mit Existierendem zu kombinieren. Auch wenn ich bis heute nicht in der Lage wäre, z.B. einen simplen Regex aus dem Kopf zu schreiben, aber solange ich zumindest weiss, wie Einer aussieht, und was er tut, muss ich ja nicht das Rad neu erfinden, sondern mir nur irgendwo ein Passendes rausziehen und es anpassen. Ist so natürlich mit Mehrarbeit verbunden, etwas, was mich jeweils dazu zwang, gewaltige Archive zu schaffen, um nicht immer alles im Web wieder neu zu suchen.

So gehe ich zumindest mit meinen 'programatischen Behinderungen' um, freue mich auf der anderen Seite dafür umso mehr, wenn's dann mal funzt. Auch wenn ich eigentlich bis heute nicht verstehe, wie man etwas, eigentlich so Einfaches, wie einen Online-Shop, derart kompliziert 'er-framework-en' kann. Wären da nicht die MIllionen von Dingen, die doch nur gebraucht werden, um den Scheiss in jeder Sprache, Währung, und sonst noch Allem Spezifischen, per Knopfdruck 'funktionabel' zu machen.

Kommt vielleicht auch daher, weil ich jahrelang mit Perl 'rumfurzte', und noch zu einer Zeit, als kein einziger der damaligen Server in der Lage gewesen wäre, überhaupt mit Dingen wie OC umzugehen, ohne schon im Leerlauf mit 110% Last zu worken...

Soviel von Einem, der gern Entwickler geworden wäre!

Ernie, ehedem from
everyauction.info
Last edited by IP_CAM on Wed Feb 25, 2015 3:50 am, edited 4 times in total.

I am no longer active at this Forum.
Please don't send Personal Messages, contact: jti@jacob.ch
---
Github OC Downloads: https://github.com/IP-CAM
2'000+ FREE OC Extensions from the World's largest Github OC Archive.


User avatar
Legendary Member

Posts

Joined
Tue Mar 04, 2014 1:37 am
Location - Switzerland

Post by CodeSpace » Wed Feb 25, 2015 2:43 am

Danke für deinen Beitrag IP_CAM. Mir ist bewusst, dass alles immer seine zwei Seiten hat. Aber als generell positiv eingestellter Mensch, denke ich, dass es für OpenCart und viele Entwickler einen großen Vorteil bringen könnte.

Wie ich schon in einem meiner kostenlosen Module geschrieben habe; Von der Community für die Community. Neben der Unterstützung für Entwickler würde ich gerne den Einstieg in E-Commerce mit OpenCart vereinfachen.
OpenCart hat sehr viel Potential auch im deutschem Sprachraum bekannt und häufig verwendet zu werden. Falls sich ein paar Leute finden, die daran Interessiert sind, wäre ich gerne bereit Zeit und Ressourcen dafür bereitstellen. ;)

User avatar
Active Member

Posts

Joined
Mon Aug 06, 2012 9:26 pm

Post by IP_CAM » Wed Feb 25, 2015 3:46 am

ich kannte Dich noch gar nicht, bisher, hier, und bin immer am Lesen, wenn's irgend wo was lernbares gibt... ;D
Errnie

I am no longer active at this Forum.
Please don't send Personal Messages, contact: jti@jacob.ch
---
Github OC Downloads: https://github.com/IP-CAM
2'000+ FREE OC Extensions from the World's largest Github OC Archive.


User avatar
Legendary Member

Posts

Joined
Tue Mar 04, 2014 1:37 am
Location - Switzerland

Post by CodeSpace » Wed Feb 25, 2015 4:51 am

OSWorX hat hier im Forum gute Arbeit geleistet und war immer sehr aktiv. Ich habe nur gelegentlich mal rein gesehen, wenn ich auf der Suche nach neue Ideen war. Seit 2.0 bin ich auch wieder aktiver auf GitHub und poste hier und da mal ein paar Bugs.
Ich entwickle lieber Module für OC ;)

User avatar
Active Member

Posts

Joined
Mon Aug 06, 2012 9:26 pm

Post by OSWorX » Wed Feb 25, 2015 6:49 am

CodeSpace wrote:.. poste hier und da mal ein paar Bugs ..
Da hast aber recht viel zu tun bei OC 2.x

Custom Development | Individuelle Entwicklung | Support & Bugfixes

Image Image Image


User avatar
Guru Member

Posts

Joined
Mon Jan 11, 2010 10:52 pm
Location - Austria

Post by CodeSpace » Wed Feb 25, 2015 8:15 pm

Naja, hier und da ist schon was zu finden. Aber es ist jetzt nichts dabei, das sich nicht schnell beheben lässt. Viel mehr Kopfzerbrechen macht mir da die VqMod/OCMod geschichte.
Ich habe da neulich mal einen neuen Ansatz getestet. Kurz gesagt, lasse ich die Grundinstallation so wie sie ist. Ich erstelle aber für alle MVCL-Ordner einen 2 Unterordner.

Normal:
catalog->controller->account->controller.php

ich habe
catalog->default->account->controller.php
catalog->opt->account->controller.php
catalog->{DESIGNNAME}->account->controller.php

Die höchste Priorität hat opt, sollte der Controller nicht da sein, wird auf das aktive Design geprüft, sonst wird default geladen.


Für mich hat das folgende Vorteile:
- Installierte Themes kann ich einfach, schnell und ohne Restmüll auf dem Server löschen.
- Ich muss keine Dateien bei der Installation von Themes überschreiben
- Grundversion bleibt updatefähig
- Übersichtliche Strukturen
- Einfache Erweiterung von Events*
- Einfache Kombination mehrere Erweiterungen
- Schnelles und automatisiertes Updaten von default auf opt möglich**

Ganz klar: Diese Methode ist nur für Entwickler und nicht für Endbenutzer.

*Meine Idee hinter opt ist der Einsatz von Events als Erweiterung.

demo-controller.php //default

Code: Select all

<?php 
class ControllerAccountDemoController extends Controller{

    public function index(){
        $name = 'test';
        return $name;
    }
}
demo-controller.php //opt

Code: Select all

<?php 
class ControllerAccountDemoController extends Controller{

    public function index(){
        $name = 'test';
        $name = $this->event->trigger('opt.democontroller.index',array($name));
        return $name;
    }
}
Muss mir mal die EventClass anschauen. Denke, da kann man sicher einiges rausholen.

**Updaten von default auf Opt
Es gibt einige gute Möglichkeiten, wie man zwei ähnliche Versionen zusammen bekommt. Man kann es z.B. über Git machen oder ein einfaches PHP-Script, das Unterschiede in Dateien sucht. Dabei muss man ja lediglich nach Even-Zeilen suchen, prüfen ob es opt.x ist und diese Zeile dann löschen und gegen die neue Datei prüfen.
Eleganter ist es natürlich, wenn man es über Git/SVN mergen würde.

Ich werde mir heute mal Gedanken machen, welche Weg ich gehe. Da ich für einen neuen Shop sehr viele Änderungen vornehmen muss, sollte der Ansatz schon gut überlegt sein.

User avatar
Active Member

Posts

Joined
Mon Aug 06, 2012 9:26 pm

Post by OSWorX » Wed Feb 25, 2015 8:39 pm

Bevor du daran weitermachst, würde ich mir das hier ansehen (das Konzept gibt es bereits sehr ausgereift):
OpenCart Override Engine

Custom Development | Individuelle Entwicklung | Support & Bugfixes

Image Image Image


User avatar
Guru Member

Posts

Joined
Mon Jan 11, 2010 10:52 pm
Location - Austria

Post by CodeSpace » Wed Feb 25, 2015 10:02 pm

OSWorX wrote:Bevor du daran weitermachst, würde ich mir das hier ansehen (das Konzept gibt es bereits sehr ausgereift):
OpenCart Override Engine
Danke, ich habe es eben nur überflogen, finde den Ansatz sehr gut und ist meinem Grundgedanken ähnlich. Hast du damit Erfahrugnen, verwendest du es selber, ...?

User avatar
Active Member

Posts

Joined
Mon Aug 06, 2012 9:26 pm

Post by OSWorX » Thu Feb 26, 2015 12:09 am

CodeSpace wrote:Hast du damit Erfahrugnen, verwendest du es selber, ...?
Nein, bisher keine Zeit dafür.
Weiß aber dass der Entwickler gute Arbeit leistet.

Custom Development | Individuelle Entwicklung | Support & Bugfixes

Image Image Image


User avatar
Guru Member

Posts

Joined
Mon Jan 11, 2010 10:52 pm
Location - Austria

Post by IP_CAM » Thu Feb 26, 2015 1:23 am

OpenCart Override Engine:
Es gibt aber offenbar keinen Weg zurück, wenn's mal installiert ist, ohne 'manuell einzugreifen', da doch Einiges an Source verändert bzw. filemässig ersetzt wird, und Originale *-markiert. Würde mich wohl dazu zwingen, noch mal von vorn zu beginnen, da ich gelegentlich Mod's in Source integriere. Was ich aber noch gar nicht weiss, für Shop-User bringt's wahrscheinlich wenig oder nichts, zumindest funktions- und/oder performance-mässig ?
Und dann ja sowieso nichts, wenn ich schlussendlich mal alle VqMod's hardcode-mässig verbaut hätte, denn 'schneller' als das ist ja sowieso nichts. Zumindest technisch gesehen und ohne zusätzliche Add-On Mod's like Cache and more...?!

Ernie

PS. Uebrigens, performance-mässig, das Beste, was ich je fand, steht hier, ein paar simple Linien, und ich kann sogar die Zählerei im Top-Menue eingeschaltet lassen. Geht ja auch gar nicht anders, bei kleinen Shops mit teils noch leeren Gestellen..., will man nicht mit Sicherheit die Kundschaft vergraulen.
http://devs.mx/topic/380-caching-openca ... ry-counts/

I am no longer active at this Forum.
Please don't send Personal Messages, contact: jti@jacob.ch
---
Github OC Downloads: https://github.com/IP-CAM
2'000+ FREE OC Extensions from the World's largest Github OC Archive.


User avatar
Legendary Member

Posts

Joined
Tue Mar 04, 2014 1:37 am
Location - Switzerland

Post by CodeSpace » Thu Feb 26, 2015 4:22 am

Ich habe es mir mal angesehen. Die Idee dahinter ist wirklich nicht schlecht. Leider fehlt aber dennoch die Trennung zwischen OC und Erweiterungen.
In der ganzen Funktion sind noch ein paar Fehler. Ich habe es aber mal so erweitert, dass ich das mit meiner Methode umsetzen kann. Muss mir nur mal die Leistung anschauen.

User avatar
Active Member

Posts

Joined
Mon Aug 06, 2012 9:26 pm

Post by CodeSpace » Tue Mar 03, 2015 10:31 pm

Hallo

Hoffe der Beitrag wird nicht zu lange. Würde gerne eure Meinung zu meiner Idee / Umsetzung wissen.

Ziel der Modifikation
- OpenCart muss updatefähig sein
- Erweiterungen / Änderungen an OpenCart übersichtlich gruppieren
- Trennung zwischen OpenCart und Erweiterungen
- Einfaches aktivieren/deaktivieren von Modifikationen
- Weitest möglich, keine Programmierkenntnisse
- Einfache Integration
- Downgrade muss möglich sein (Deinstallation der Erweiterung)
- Stabil (Fehlerquellen reduzieren)
- geringst mögliche Lasterzeugung / hohe Performance
- einfache, kleine & schnelle Backups

Die Idee - Der Grundgedanke
Wer kennt es nicht; Ein Theme oder Modul wird installiert, es funktioniert nicht oder man möchte es gegen ein anderes Modul tauschen. Schon geht die Suche nach allen Dateien los. Und wehe, man musste eine Datei von OpenCart überschreiben. Dann darf man auch noch die passende Version von OC downloaden und die Dateien wieder austauschen.
Nach einem Monat weiß man eh nicht mehr, wo man für welche Erweiterung was gemacht hat.

Genau hier möchte ich ansetzen. Absolute Trennung zwischen OpenCart und ALLEN Modifikationen und Erweiterungen. Egal ob man nur eine neue Datei hinzufügt oder eine Datei überschreibt. Das Ganze dann auch noch sauber und übersichtlich in einem Ordner und der Alptraum hat ein Ende. Dann kann man OpenCart auch einfach mit einer anderen (oder gleichen) Version überschreiben und die Erweiterungen sind nicht im Weg oder gehen (bei Änderungen an OC) verloren.

Mit einer einfache Extension-Config kann man Erweiterungen definieren. Möchte man eine Erweiterung deaktivieren, einfach den Eintrag löschen, auskommentieren oder den Pfad mit "_" verfälschen. Schon wird es nicht mehr beachtet.
Die Integration von Erweiterungen erfolgt einfach durch den Upload in einen Ordner und dem Eintrag in die Extension-Config. Löschen ist genau so einfach. Dazu muss man kein Programmierer sein.

Der Downgrade / die Deinstallation der Modifikation ist kein Hexenwerk.
Einfach den Ordner für die Erweiterungen löschen, den system/ Ordner überschreiben und die index.php´s ersetzen. Was dann noch über bleibt, ist die originale Version von OpenCart, wie am ersten Tag, so wie alle Bilder, Uploads und Downloads.
WICHTIG: Wenn eine Erweiterung eine Änderung z.B. an der DB vorgenommen hat, wird diese nicht rückgängig gemacht. Die Modifikation hat logischerweise keinen Einfluss darauf, was die Erweiterungen machen.

So, und wie bekommen wir das ganze jetzt stabil für eine gute Leistung? Genau, einfach cachen.
Am Besten diesen auch noch variabel halten, dann ist die Entwicklung einfacher. Dazu kann man aus 3 möglichen Cache-Einstellungen wählen - Full, Link oder None.

Aktueller Stand der Modifikation
Mein größtes Augenmerk hat die Sicherheit, Stabilität und Leistung. Gleich danach versuche ich möglichst wenig Eingriffe an der Grundinstallation von OC vorzunehmen.

Die Ordnerstruktur
- admin
- catalog
- extension
- image
- system

Geänderte Dateien
- index.php
- config.php
- admin/index.php
- admin/config.php
- system/startup.php
- engine/action.php
- engine/event.php (wird noch geändert)
- engine/loader.php

Neue Dateien / Ordner
- system/config/exntesion.php
- system/library/extension.php
- extension/

Eine Erweiterung integrieren
Normal wird der Ordner Upload einfach in root geladen. Jetzt muss der Ordner unter extension/{Modulname}/geladen werden. In der config/extension.php wird ein Eintrag für die Erweiterung gesetzt, mit dem Ordnernamen.
Aktuell gibt es keine Funktion, die bei (De)Installation von Erweiterungen den Cache leert. Das wird aber noch gemacht. Daher von Hand alles aus dem Cache leeren. Und Fertig ist die Integration.

Cache-Einstellungen
Es gibt im Moment 3 Möglichkeiten für den Cache.

- None / false
Es wird kein Cache angelegt. Für kleine bis mittlere Shops oder (ich schätze mal) unter 20 großen Erweiterungen sollte die Geschwindigkeit sehr gut sein. Gibt einfach zu viele Faktoren um hier genaue Zahlen zu nennen.

- Full
Das ist die stabilste Version, mit geringsten Dateizugriffen und wohl auch die schnellste. Bei der Einstellung gibt es ein paar Punkte zu beachten.
1. Bei Themes sollten .css-Dateien am besten von Hand angepasst werden. Es ist eine Funktion eingebaut, die die .css für den Cache ändern kann, ist aber noch eher eine fortgeschrittene Beta.
2. Der Extension-Cache Ordner (nicht system/cache) sollte mit einer .htaccess gegen Zugriff geschützt werden.
3. Nach jeder Änderung einer Datei, muss die dazugehörige Cache-Datei aus dem Cache gelöscht werden.
4. Der Cache hat kein "Haltbarkeitslimit". Einmal angelegt, bleibt er bestehen, bis er gelöscht wird.

- Link
Optimal für die Entwicklung. In diesem Modus ist der Cache nur ein Link auf die "echte" Datei. Änderungen werden daher direkt übernommen und können sich auf die Stabilität auswirken.

Warum cachen, wenn eh die originale Datei verwendet wird?

Die genaue Technik zu erklären wäre sehr umfangreich, daher eine einfache Zusammenfassung. Bei jeden Aufruf wird geprüft ob eine Cache-Datei vorhanden ist. Wenn diese vorhanden ist, wird nicht nach neuen Dateien (in Erweiterungen oder in OC) gesucht sondern direkt die verlinkte Datei verwendet. Das spart Zeit, Ordnerzugriffe und Leistung.

Überschreiben & Erweitern
Hier kommt der lustige Teil. Wie kann man was überschreiben und erweitern?

Es ist wichtig, zu beachten, dass jeder Typ (Controller, Model, View, Language, Css, Style, Library,...) anders gehandelt und verarbeitet wird. Hat man das System erst mal verstanden und weiß, wie was funktioniert, spart es Zeit und auch Leistung. Es wird für jeden Typ die optimale Lösung angewandt.

Extensions (egal welcher Art) haben Prioritäten. Würde Extension-B einen Controller von Extension-A überschreiben, ist das hier nicht der Fall. Die Erweiterung mit der höchsten Prio. ist auch die, die dann verwendet wird. Gleiche Prio. ist nicht möglich, somit auch kein zufälliges Ereignis.

Unter extension/ gibt es den Ordner _default. Dieser hat IMMER die höchste Prio. Darin enthalten sind auch Änderungen an OpenCart, die dann z.B. im Admin unter Module die Module aus Erweiterungen anzeigen. Jede Extension kann die vollständige Struktur von OpenCart enthalten, ausgenommen /image. Diese müssen immer unter /image im Hauptverzeichnis geladen werden.

Neuen Controller (ControllerCommonDemo) anlegen
Als erstes legen wir die neue Extension (demo) an und bilden den Pfad, wie in OpenCart üblich, ab.

Code: Select all

extension/demo/(catalog|admin)/controller/common/demo.php
Danach noch den Quellcode rein, speichern und fertig. Wenn das die erste (catalog|admin)/controller/common/demo.php ist, muss keine Änderung am Cache vorgenommen werden.

Controller Common Home überschreiben
Die Ordnerstruktur für den controller haben wir schon. Jetzt legen wir nur noch eine home.php dazu.

Code: Select all

extension/demo/catalog/controller/common/home.php
Die Datei sollte erst mal den gleichen Inhalt wie das Original haben. Dann macht man die Änderungen, und speichert diese unter extension ab. Noch den Cache leeren und schon ist es überschrieben ohne das Original aus OC zu ändern.

Sprachdateien erweitern/ändern
Im Gegensatz zu Controllern muss die Sprachdatei nicht den gleichen Inhalt, wie die von OC haben. Hier reicht es, wenn man die neuen Werte, oder die Werte, die man überschreiben möchte, einfach einfügt. Beispiel an der english.php

Code: Select all

/catalog/language/english/english.php
In der Extension abbilden

Code: Select all

extension/demo/catalog/language/english/english.php
Neue Werte eintragen oder überschreiben

Code: Select all

$_['text_yes'] = 'Yeah';
$_['text_entwicklung_macht_spass'] = 'Demo';
Beim Erweitern (nicht überschreiben) werden alle Dateien bis auf Sprache (language/*) gleich behandelt.
Beim FullCache wird eine neue Sprachdatei angelegt, die alle Werte aller Sprachdateien enthält. So wird aus der Sprachdatei von OpenCart und allen Extensions eine neue. Bei Link wird auf alle Dateien verlinkt.

Mehrfaches überschreiben
Jaja, der wohl lustigste Teil an der ganzen Geschichte. Alles, was ich bisher erklärt habe, ist fertig und funktioniert in einigen Tests ohne Probleme. Alles was hier kommt, ist noch Theorie.

Meine Idee war die Verwendung einer ähnlichen Funktion, wie die Event-Funktion, für die Kombination mehrere Änderungen aus unterschiedlichen Extensions. Mal ein Beispiel mit dem Controller CommonHeader.

Code: Select all

//default
$data['links'] = $this->document->getLinks();
//add extension event trigger
$data['links'] = $this->extension->triggerEvent('demo.add_link',$data['links']);
//the call
$result = $this->extension->triggerEvent( extension_name.function , parameter);

Code: Select all

class DemoControllerCommonHeader extends Controller {
	public function add_link($param)
    {
        $link_to_add = 'http://www.google.de';
        if(!in_array($link_to_add,$param)) {
            $param[$link_to_add] = array(
                'href' => $link_to_add,
                'rel' => 'canonical'
            );
        }
        return $param;
    }

triggerEvent würde in diesem Fall den neuen Controller aufrufen und alle Parameter (bis auf den ersten) weiter geben. Jeder Entwickler könnte selber entscheiden ob er alle Parameter in einem Array übergibt oder jeden Wert als einzelnen Parameter angibt.
Wer ordentlich entwickelt, wird seine trigger eh mit einem Kommentar ähnlich diesem versehen

Code: Select all

        /**
         * extension: demo
         * function: add_link
         * param: all links
         * do: add new link for canonical
         * return: all links and new canonical link
         */
         $data['links'] = $this->extension->triggerEvent('demo.add_link',$data['links']);
Das waren meine Gedanken und Ideen für die nächsten Schritte. Zuletzt noch das Thema Backup.
Es gibt viele unterschiedliche Arten, Backups anzulegen. Ich empfehle hier ein Grundbackup des ganzen Systems anzulegen und dann immer nur noch alles aus extension/ bis auf extension/__cache/
Das sollte die Größe der Backups extrem reduzieren und das Wiedereinspielen stark beschleunigen. Unter Umständen noch Images, Up- und Downloads...

User avatar
Active Member

Posts

Joined
Mon Aug 06, 2012 9:26 pm

Post by IP_CAM » Wed Mar 04, 2015 1:32 am

Ich stehe jetzt vor dem Problem, mit deutschen 'Worten' umgehen zu müssen. Wenn ich's also richtig 'sehe', würde dadurch VqModding überflüssig, vor Allem, wenn's gelänge, mit 'konzertiertem' Mehrfach-Ueberschreiben hintereinander Mod's laufen zu lassen, wobei jeder 'folgende' quasi nur noch auf dem 'Letzzustand' weiter 'aufbaut'. So etwa ähnlich wie VqMod- Add-on's. Oder liegt ich voll abseits?
Ansonsten, hat mich am meisten begeistert, an OC, der völlig transparente Aufbau, ohne jedes überflüssige Geschreibsel, was die jeweilige Routine eigentlich soll...! Da darf man Nächte damit verbringen, es selber auszuprobieren, die reinste Freude! :choke:
Ernie

I am no longer active at this Forum.
Please don't send Personal Messages, contact: jti@jacob.ch
---
Github OC Downloads: https://github.com/IP-CAM
2'000+ FREE OC Extensions from the World's largest Github OC Archive.


User avatar
Legendary Member

Posts

Joined
Tue Mar 04, 2014 1:37 am
Location - Switzerland

Post by CodeSpace » Wed Mar 04, 2015 3:25 am

Hallo Ernie

Es gibt mehrere Möglichkeiten beim Überschreiben. Um es an einem Beispiel zeigen zu können, gehen wir mal von 1 Erweiterungen aus.

Order:
/extension
/_default
/extension_1

Datei:
extension/extension_1/catalog/controller/common/home.php

In diesem Fall gibt es 2 Möglichkeiten.

1. Ich lasse die Datei unter diesem Pfad, dann wird diese an Stelle von
catalog/controller/common/home.php
verwendet.
2. Oder ich kopiere die originale home.php nach
extension/_default/catalog/controller/common/home.php
und füge dort

Code: Select all

$this->extension->triggerEvent(extension_1.addNewTitle,$this->document);
ein.

Etwas anders sieht es aus, wenn man 2 Extensions hat, die die gleiche Datei überschreiben.

Order: [Priorität]
/extension
/_default [99]
/extension_1 [98]
/extension_2 [97]

Dateien:
extension/extension_1/catalog/controller/common/home.php
extension/extension_2/catalog/controller/common/home.php

Ein paar Beispiele:
_default hat keine home.php
home.php von extension_1 wird verwendet. home.php von extension_2 wird nicht ausgeführt/beachtet.

_default hat eine home.php ohne triggerEvent() und ist absolut identisch zu OpenCart.
Die home.php von extension_1 und extension_2 wird nicht beachtet.

_default hat eine home.php ohne triggerEvent() und ist nicht identisch zu OpenCart.
Es ist möglich Änderungen direkt in der _default - home.php zu machen. Das ist aber absolut schlecht, da so das updaten sehr sehr umständlich wird und das ganze System an Sinn verliert.
Aber in diesem Fall, wird die _default - home.php verwendet und die extensions 1 und 2 nicht beachtet.

_default hat eine home.php mit 1 triggerEvent() und ist absolut identisch zu OpenCart.
Die absolut beste Vorgehensweise. Kostet aber etwas mehr Zeit, wenn man fertige Module dafür verwenden möchte. Aber der beste Ansatz, wenn man selber entwickelt.
In diesem Fall wird die _default - home.php verwendet, nicht die von OC, und es wird die Funktion aus extension_1 aufgerufen.

_default hat eine home.php mit mehreren triggerEvent() und ist absolut identisch zu OpenCart.
Die beste Lösung für mehrfaches überschreiben. In diesem Fall wird auch die Priorität der Extensions nicht mehr beachtet. Der Code wird "von Oben nach Unten" ausgeführt. Nicht erst alle Trigger von extension_1 und dann alle von extension_2...

Die neue _default - home.php

Code: Select all

class ControllerCommonHome extends Controller {
    public function index() {
        
        $this->document->setTitle($this->config->get('config_meta_title'));
        //extension_1 change title to 'Demo'
        $this->extension->triggerEvent('extension_1.changeTitle',$this->document);
        //extension_2 change title to 'OpenCart'
        $this->extension->triggerEvent('extension_2.changeTitle',$this->document);
        

        $this->document->setDescription($this->config->get('config_meta_description'));
        
        //extension_3 change description
        $this->document->setDescription( $this->extension->triggerEvent('extension_3.functionName',''));
        
        $this->document->setKeywords($this->config->get('config_meta_keyword'));

        //extension_1 set new Keywords
        $this->extension->triggerEvent('extension_1.newKeywordsForMe',$this->document);
        
        if (isset($this->request->get['route'])) {
            $this->document->addLink(HTTP_SERVER, 'canonical');
        }

        $data['column_left'] = $this->load->controller('common/column_left');
        $data['column_right'] = $this->load->controller('common/column_right');
        $data['content_top'] = $this->load->controller('common/content_top');
        $data['content_bottom'] = $this->load->controller('common/content_bottom');
        $data['footer'] = $this->load->controller('common/footer');
        $data['header'] = $this->load->controller('common/header');

        if (file_exists(DIR_TEMPLATE . $this->config->get('config_template') . '/template/common/home.tpl')) {
            $this->response->setOutput($this->load->view($this->config->get('config_template') . '/template/common/home.tpl', $data));
        } else {
            $this->response->setOutput($this->load->view('default/template/common/home.tpl', $data));
        }
    }
}
Durch das unabhängige Erstellen eigener Trigger, kann man die Parameter und Rückgabe selber definieren. Wie man in diesem Beispiel sieht, kann man entweder das Object $this->document übergeben und dann in der Extension verarbeiten oder ich gebe mit der Funktion der Extension einen Wert zurück. Absolute Freiheit.
Eine goldene Regel sollte man aber beachten.
Never changed the default code!

Zum Upgraden kann man dann einfach die Trigger übernehmen.

Auch in Extensions kann man diesen Trigger verwenden. Wobei ich empfehlen würde, alle Trigger immer in einer Datei zu verarbeiten.
So etwa ähnlich wie VqMod- Add-on's. Oder liegt ich voll abseits?
Das ist richtig. Wobei es einen Unterschied gibt. VqMod erstellt aus den AddOn - Anweisungen eine neue Datei, die dann aufgerufen wird. Mein System führt die Modifikationen bei jedem Aufruf direkt aus. Beides hat seine Vor- und Nachteile.
Da darf man Nächte damit verbringen, es selber auszuprobieren, die reinste Freude!
Falls du damit meinst, ob du es selber mal testen darfst, dann sehr gerne. Möchte nur noch die letzten Punkte fertig machen, dann lasse ich dir die Version zukommen. ;)

https://i.imgur.com/FVf0OnJ.png

User avatar
Active Member

Posts

Joined
Mon Aug 06, 2012 9:26 pm

Post by IP_CAM » Wed Mar 04, 2015 7:52 am

>>Falls du damit meinst, ob du es selber mal testen darfst, dann sehr gerne<<
ich meine OC ganz generell, es war schon etwas gewöhnungsbedurftig, sich damit zu 'familiarisieren', da eher sehr wenig // Information // <!-- oder ähnliches --> vorhanden ist, um 'relativen' Newbies den Weg zu ebnen...
Ernie

I am no longer active at this Forum.
Please don't send Personal Messages, contact: jti@jacob.ch
---
Github OC Downloads: https://github.com/IP-CAM
2'000+ FREE OC Extensions from the World's largest Github OC Archive.


User avatar
Legendary Member

Posts

Joined
Tue Mar 04, 2014 1:37 am
Location - Switzerland
Who is online

Users browsing this forum: No registered users and 5 guests