Entwickler Dokumentation

Hallo,
da ich leider bisher keine zufrieden stellende Antwort gefunden habe, stelle ich hier zum wahrscheinlich x-ten Mal die Frage nach einer Entwickler-Dokumentation.
Ich hatte vor ca. einem Jahr eine Anfrage bezüglich Erweiterung eines Oxid-Shops. Ich habe diesen Auftrag nicht angenommen, weil der Einarbeitungsaufwand zu hoch gewesen wäre. Der Kunde hat offensichtlich noch niemanden gefunden für diesen Auftrag. Ich würde vermuten, daß es daran liegt, daß auch anderen dieser Aufwand zu hoch ist. In den letzten Tagen habe ich mir die Community Edition installiert. Das Coding scheint recht verwinkelt zu sein, was wohl hoffentlich auch daran liegt, daß man solche Erweiterungen nur unter Berücksichtigung der vorgegebenen Richtlinien machen sollte. Aber wo finde ich die Beschreibung dieser Richtlinien? Die API-Dokumentation reicht nicht aus. Steht das schon irgendwo im Internet? Ein Buch git es auch noch nicht, oder? Oder habe ich das nur nicht gefunden?
Im Admin-Bereich habe ich jetzt endlich die Stelle gefunden für Modul-Erweiterungen. Mal sehen ob ich damit weiter komme. Die war aber sehr gut versteckt! Ich hatte bisher nur eine Information gefunden, daß das im Admin-Bereich möglich ist.

Vor den Erfolg haben die Götter nun mal den Schweiß gesetzt…

Ohne intensive Einarbeitung wird das nichts, Bücher wie “OXID-Entwickler in 24 Stunden” oder “OXID-Entwicklung für Dummies” gibt es nicht und wird es auch nicht geben, weil das Ganze ein sehr umfangreiches und komplexes Thema ist.

Ich beschäftige mich nun seit 6 Monaten intensiv mit OXID, und kann so langsam sagen, dass ich das so einigermaßen verinnerlicht habe…

Mal eben ein Modul schreiben funktioniert nicht.

Ich hatte angefragt, ob es eine komplette Entwickler-Dokumentation gibt! Gibt es die oder nicht?

Es kommt drauf an, was du unter “kompletter Entwicklerdokumentation” verstehst. Den dokumentierten Sourcecode kannst du hier abrufen. Darin siehst du auch die Abhängigkeiten der Klassen.

Vielen Dank. Das hatte ich schon gefunden. Aber das ist eben nicht ausreichend. Ich suche auch nicht unbedingt einen kostenlosen Download. Ich bräuchte eine Beschreibung der internen-Abläufe - soweit das ein Entwickler wissen müßte. Ich habe z.B. einen Artikel umgelenkt auf ein PHP-File. Ich kann darin den Warenkorb einlesen, neue Einträge reinlegen. Aber ich weiß nicht, ob ich noch irgend eine Art von commit machen müßte. Wahrscheinlih ist es der falsche Weg. Es ist wahrscheinlich ratsam eine Klasse anzulegen, oder? Ich möchte hier jetzt aber keine kostenlose Beratung, sondern nur den Weg zum richtigen Einstieg gezeigt bekommen. Es nützt mir ja auch nichts, das aktuelle Coding zu verstehen. Für mich wäre wichtig, welche Aussagen der Hersteller dazu macht. Auf die könnte ich mich verlassen. Alles andere ist ja nur basteln und es bleibt eine nicht gerade geringe Unsicherheit.

Ausser der Dokumentation des Source Codes, den Tutorials und den vereinzelt erhältlichen Open-Source-Modulen gibt es zur Zeit leider nichts.

Für andere Systeme gibt es zumindest Beipiele. Gibt es das bei Oxid nicht?

Ich war kurz davor, alles hinzuschmeißen. Jetzt habe ich meine erste Klasse drin und auch gefunden, daß ich für einen Artikel einfach ein Smarty-Template eintragen kann. Damit bin ich etwas ausgesöhnt. Ich hätte das aber sicher nicht hinbekommen, wenn ich nicht Erfahrungen mit Smarty hätte und mich in den letzten zwei Tagen durch die Verzeichnisstruktur durchgequält hätte. Es wird nicht angegeben wo das Template abgelegt werden soll?
Könnte da nicht mal ein erfahrener Berater zusammen mit dem Hersteller ein Buch schreiben? Dieses Forum bzw. die Moderatoren wären doch sicher dadurch entlastet!
Aus eigener Erfahrung würde ich sagen, daß Entwickler da zumeist etwas betriebsblind sind.

[QUOTE=abc123;21535]Es wird nicht angegeben wo das Template abgelegt werden soll?[/QUOTE]
Zum Beispiel hier wird angegeben, wo ein neues Template abgelegt werden soll. Hast du das Handbuch mal durchgelesen?

[QUOTE=abc123;21535]Könnte da nicht mal ein erfahrener Berater zusammen mit dem Hersteller ein Buch schreiben? [/QUOTE]
Klar, wäre ich auch dafür. Aber zuerst musst du jemanden finden, der ein Buch schreiben wird. Der Hersteller ist mit dem Handbuch bereits dran. Dieses ist jedoch online und nicht Entwicklerspezifisch.

In diesem Abschnitt habe ich das inzwischen auch gesehen. Ich hatte in dem Abschnitt für Entwickler ein kleines Beispiel für eine Klasse gefunden. Ich finde das jetzt so schnell nicht mehr. Es ging um einen Renderer. Dort stand es nicht mit dabei. Und dort wo man im Admin-Bereich den Template-Namen eingibt, ist bei mir kein Fragezeichen zu sehen und auch kein Hilfstext implementiert.

ein handbuch ist so aktuell wie das altpapier in der tonne
es gibt gewiss wichtigere dinge, die z.b. immens umsatzschädigend sind wenn z.b. bei bezahlmodulen was nicht funktioniert, was deutlich höhere prioritäten haben sollte als ein handbuch was niemals aktuell wäre und auch nicht aktuell zu halten ist.
bis der druck band 1 fertig ist, wäre längst schon shopversion 2 oder 3 öffentlich.

[QUOTE=laramarco;21544]ein handbuch ist so aktuell wie das altpapier in der tonne

[QUOTE]

Da bin ich nicht deiner Meinung. Gewisse Komponenten werden auch in Version 4.3, 4.4 oder 5 noch gültig sein. Auch Altpapier kann manchmal nützlich sein… Und da das Oxid-Handbuch eine Onlineausgabe ist, wird es kein Altpapier geben. :slight_smile:

Es muss ja nicht gleich ein Buch sein, aber etwas mehr Dokumentation über die internen Abläufe und die dahinterliegenden Konzepte wäre schon wünschenswert. Die API-Dokumentation ist ziemlich dürr und erklärt nicht das Zusammenspiel der Komponenten. Für oxConfig erhält man z.B. als “Detailed Description”: “Main shop configuration class”. Da gäbe es bestimmt mehr dazu zu erzählen.

Etwas mehr Doku über die “Interna” würde im Endeffekt auch den Shopbetreibern zugute kommen, weil die Einstiegshürde für Programmierer niedriger wäre und damit mehr Input aus der Community kommen würde, was ja eigentlich der Sinn der Open-Source-Geschichte ist.

Als Shopbetreiber interessieren mich die Internas gar nicht, das muss nur funktionieren.
Mir reicht es wenn man die Templates und CSS ein wenig anpassen kann. Dafür bietet das Handbuch eine gute und stets aktuelle Hilfe.

Ich könnte Wetten abschliessen, dass kaum einer in eine Papierversion gucken würde, da die Suche etc viel umständlicher ist als online. Wo hat man das Altpapier dann wieder hingelegt, etc. zuguterletzt guckt man dann doch online, weil es einfach die aktuellere und vollständigere Doku ist.

Meistens will man ja gezielt etwas nachlesen und nicht, wie bei einem Roman von vorne bis hinten durchlesen. Außerdem muss man bei dem Handbuch doch stets am Rechner sitzen und eigene Einstellungen nachzugucken und auszuprobieren.

CYA
Firefax

sicher, als shopbetreiber zahle ich den techni für anpassungen, interessiert mich ein handbuch nix überhaupt nix

und daß sich ein techni auch techni nennen kann, dafür gibts ja wohl schulungen und anzido-akademie.

für mich als shopbetreiber zählt es viel mehr, daß das haus oxid, welches den grundstein vergibt, eine reibungslos funktionierende version rausbringt und nicht die leuts für erstellen von handbüchern oder online handbücher abkommandiert.

[QUOTE=laramarco;21558]sicher, als shopbetreiber zahle ich den techni für anpassungen, interessiert mich ein handbuch nix überhaupt nix
[/QUOTE]

[QUOTE=Firefax;21553]Als Shopbetreiber interessieren mich die Internas gar nicht, das muss nur funktionieren.
Mir reicht es wenn man die Templates und CSS ein wenig anpassen kann. Dafür bietet das Handbuch eine gute und stets aktuelle Hilfe.
Firefax[/QUOTE]

Das OXID-Forum wimmelt nur so von solchen Beiträgen! Das ist mir ein Rätsel. Habt ihr zwei mal gelesen, in welchem Forum Ihr schreibt? Da steht doch dick und fett Developers oben drüber!

Wenn euch das nicht interessiert, bitte. Wie schon ganz richtig erkannt, muss es das auch nicht.

Aber dann müllt doch nicht die Threads mit solchem Zeug zu.

Ich als Entwickler würde mir manchmal auch eine ausführlichere Dokumentation wünschen und ich kann auch den Wunsch nach einer Printausgabe verstehen.

richtig, aber ich bezahle eine oxid shopversion um damit zu verkaufen, um damit meinen lebensstandard zu erfüllen

ich kaufe keine shopversion, weil der hersteller sich mit dingen und zeugs die zeit totschlägt, aber umsatzschädigende bugs nicht erkennt oder löst.

wenn entwickler ein handbuch wünschen, dann bitte aber nicht auf meine kosten.

[QUOTE=laramarco;21596]richtig, aber ich bezahle eine oxid shopversion um damit zu verkaufen, um damit meinen lebensstandard zu erfüllen

ich kaufe keine shopversion, weil der hersteller sich mit dingen und zeugs die zeit totschlägt, aber umsatzschädigende bugs nicht erkennt oder löst.

wenn entwickler ein handbuch wünschen, dann bitte aber nicht auf meine kosten.[/QUOTE]

Wer sagt denn, dass das auf deine Kosten geht? Was ist das für eine komische Schlussfolgerung? Jeder Entwickler, der von außen OXID unterstützt, indem er Module schreibt oder Bugs behebt, ENTLASTET die internen Programmierer doch.

Je mehr man diese Programmierer einbezieht, desto mehr Zeit haben die fest bei OXID angestellten Programmierer für das, was du forderst. Das ist sicher mit eine Idee gewesen, beim Schritt OXID als OpenSource zu veröffentlichen.

Wenn du die Externen auschließt, und das tust du, wenn du ihnen keinen vernünftigen Einstieg ermöglichst, desto weniger Köpfe beschäftigen sich mit Bugs und Features!

Es ist also nur sinnvoll, wenn OXID mit der Dokumentation so weiter macht.

[QUOTE=laramarco;21596]richtig, aber ich bezahle eine oxid shopversion um damit zu verkaufen, um damit meinen lebensstandard zu erfüllen

ich kaufe keine shopversion, weil der hersteller sich mit dingen und zeugs die zeit totschlägt, aber umsatzschädigende bugs nicht erkennt oder löst.

wenn entwickler ein handbuch wünschen, dann bitte aber nicht auf meine kosten.[/QUOTE]

Im Gegensatz zu dir haben nicht alle eine EE, sondern teilweise auch eine CE. Und da diese Open Source ist, besteht in jedem Fall das Interesse diese weiterentwickeln zu lassen. Ob dies selber oder durch einen Entwickler passiert ist eigentlich egal. Um die Weiterentwicklung zu vereinfachen wäre ein Entwicklerhandbuch wünschenswert.

ja aber warum fordert ihr das von OXID ???

warum muß ein autor der hersteller dieses produktes sein ??

wieviele bücher werden von “neutralen” geschrieben, und da bleibe ich standhaft bei meiner meinung - oxid hat dafür schlicht und einfach keine resourcen übrig oder sollte diese in notwendigere bugbehebung stecken denn schließlich gehen DIE uns alle an.