Haben Sie schon mal das Bedürfnis verspürt, ein Modul anpassen zu müssen?

[FrankH]

Wer erfolgreich versucht hat PHP zu erlernen, kann natürlich auch ein Modul an seine Bedürfnisse anzupassen.
Das Problem dabei ist die Arbeit, die auf einen zukommt, wenn es ein Update für das Modul gibt.
Dann muss man die Änderungen am Modul mit den eigenen Erweiterungen zusammenführen, und das kann zeitraubend sein.

Ich stehe momentan vor dem Problem, das Modul MPForm an site-spezifische Bedürfnisse anpassen zu müssen. Ich habe mir dazu folgendes ausgedacht:

Ziemlich an den Anfang der Datei kommt:

Code:

// include private functions, if available
if (file_exists(WB_PATH .'/modules/mpform/private.php')) {
    include(WB_PATH .'/modules/mpform/private.php');
}

An eine oder mehrere Stellen im Code kommt:

Code:

// execute private function in private.php, if available
if (function_exists('private_function')) {
     private_function($parameter);
}

Wenn es mehrere Stellen sind, sollten die Funktionsnamen sich natürlich unterscheiden.

Die Datei private.php im Modulverzeichnis kann dann jeder gestalten, wie er gerne möchte, und bei einem Update gibt es keine Anpassungsarbeiten (falls der private Code nicht zufällig vom Update betroffen ist).

Zumindest ist mir nichts besseres eingefallen, wie ich mit möglichst wenig Aufwand kundenspezifische Änderungen in das Modul bekomme. Ich möchte mit der Umfrage mal in die Runde fragen, wie die Meinungen zu so einem Vorgehen sind.

[thorn]

Hallo,

ich sehe den Nutzen nicht so wirklich.
Änderungen an einem Modul sind kaum nur mit ein, zwei include() erledigt -- man wird so oder so auch den Code des Modules ändern müssen. So eine Schnittstelle nutzt da glaube ich wenig.

Trotzdem ist die Idee an sich nicht schlecht. Wenn du auf diese Art deine Änderungen durchführst, kannst du schonmal den größten Teil außerhalb des Modul-Codes ablegen, sodaß bei einem Update weniger anzupassen ist.

Also als private Lösung sicher gut -- als generelle Lösung sehe ich den Nutzen halt nicht.


thorn.

[Ralf (Berlin)]

Die einfachste und sauberste Lösung ist, objektorientiert zu arbeiten. Für Erweiterungen vereerbe ich die Klasse und passe die neue Klasse an meine Bedürfnisse an und erweitere den Funktionsumfang nach Belieben, ohne auch nur eine einzige Zeile des ursprünglichen Moduls ändern zu müssen.

Um Schnittstellen zu realisieren kann das Ausgangsmodul auch abstrakte Klassen einführen die von den jeweiligen Erweiterungen überschrieben werden (Beispiel: ShortLink beschreibt eine abstrakte Klasse um auf Adressdaten anderer Module zugreifen zu können).

Gruß
Ralf

[aldus]

Haben Sie schon mal das Bedürfnis verspürt, ein Modul anpassen zu müssen?

Brülll .... ich hatte schon ein paar Mal das Bedürfnis einen Strick zu nehmen und den (copy 'n paste) Coder zu ####

Wie Ralf, so sehe ich es ebenso: OOP. Alles Andere ist Käse; angefangen beim Wildwuchs der
Funktionsnamen, dem unsäglichen "!function_exists" bis hin zur Pflegbarkeit/Lesbarkeit vom Code selber. Der kleine Klassiker
bei den Bildergalerien: ein Counter  Klink' den mal ohne Objektorientierung rein ...
Oder einen Logfile für die Querys zum Debuggen beim Entwickeln/Installieren ...
Vererben, Überschreiben, Erweitern ... und jut ists.

Gruß
Aldus

[WebBird]

Ich finde die Idee gut, dafür mal ein grundlegendes Verfahren zu definieren. Frameworks arbeiten da häufig mit "callbacks" oder "hooks", aber das klappt in der Regel nur, wenn man phasenbasierten Code hat. Erweiterungen können dann für jede Phase einen callback registrieren, etwa daß eine bestimmte Routine der Erweiterung ausgeführt wird, bevor eine bestimmte Routine/Phase des Originalcodes ausgeführt wird.

Allerdings sind auch hier die Anforderungen an das Framework selbst sehr hoch, und das ist das eigentliche Problem. Man kann sich halt nur dort einhaken, wo das vom Entwickler auch tatsächlich eingeplant wurde.

Sagen wir mal, ein Modul besteht aus vielen kleinen Funktionen, die nach irgendeiner Logik ausgeführt werden. Dann kann man sich sicherlich vor eine solche Funktion einhaken und z. B. Daten aus der Datenbank durch die Mangel drehen, bevor sie von der nächsten Funktion weiter verwurstet werden.

Wenn nun aber das Modul ein einziger großer Codehaufen ist (ohne Subroutinen), statt Subroutinen Sprungmarken verwendet werden oder ähnliches, steht man schon ziemlich doof da.

Und in allen Fällen hat man das Problem, daß der Entwickler des Moduls / Frameworks irgendwann auf die Idee kommen könnte, Routinen umzubenennen oder weiter aufzudröseln (aggregieren). Dann sitzt der Haken hinterher an der falschen Stelle.

Also, ansetzen muß man sicherlich bei den Richtlinien für das Erstellen von Modulen. Danach ist man aber davon abhängig, ob ein Modulentwickler sie berücksichtigt oder nicht. Verpflichten kann man ja keinen.

[chio]

In PHP bin ich bekanntlich nicht sehr sattelfest.
Mehr daheim bin ich bei Shockwave, und da ist OOP relativ üblich. Die Objekte leben ja auch deutlich länger

Ich kann jetzt mal nicht behaupten, dass OOP ein Script durchsichtiger oder leichter zu ändern macht. Im Gegenteil, das kann ziemlich undurchsichtig werden, überhaupt wenn einer im OOP-Rausch war. Da findet man sich Null zurecht, und es kommt erst recht Murks raus. Mehr als einmal habe ich diese Orgien schon wieder zurückgebaut auf das, was man tatsächlich braucht und überschauen kann.

Aber auf die Frage zurück: Module kann/muss man immer wieder mal anpassen. Solange das Teil dann das tut was es soll, spare ich mir das Update. Im Web ändert sich vieles so schnell, dass ich mir in 2 Jahren keine Gedanken mehr machen muss, was ich heute gemacht habe. Kommt ohnehin alles anders.

[Luisehahne]

Also, ansetzen muß man sicherlich bei den Richtlinien für das Erstellen von Modulen. Danach ist man aber davon abhängig, ob ein Modulentwickler sie berücksichtigt oder nicht. Verpflichten kann man ja keinen

Dan muss der Modulentwickler aber damit rechnen, dass sein Modul nicht offziell zum Tragen kommt. Denke eine einheitliche Richtlinie muss schon sein. OOP ist natürlcih zukunftsweisend. Ob sich das irgendwan ändert, wissen wir heute noch nicht. Hat aufjedenfall viele Vorteile. Das Rad muss nicht immer neu erfunden werden, sondern wird nur abgeleitet.

Ich persönlich sehe keine Probleme noch Module ohne OPP zu erstellen. Wenns ein sinnvolles Modul ist, wird sich bestimmt jemand finden der es auf OPP umsetzt. WEnn ich so überlege, die ganzen Bildergalerien, ist OOP eine sinnvolle Angelegenheit. OB Settings, DB Connect, Inhaltsboxen darstellen, du brauchst es nur einmal, veerbst es und hast viel Programmierarbeit gespart (wers beherrscht). Aber wir müssen ja alle laufend neue SAchen lernen, weil alles schnell überholt ist.

Siehe WEbbird "Sprungmarken" kenn ich noch von Basic her aufm C64er

Dietmar

[WebBird]

Siehe WEbbird "Sprungmarken" kenn ich noch von Basic her aufm C64er

Tja, und es gibt sie immer noch. Viele verteufeln sie ja, genau wie das vorzeitige Beenden von Schleifen, aber beides hat seine Daseinsberechtigung . Kommt halt immer drauf an, was man damit macht.

Wie gesagt, ich halte es für eine gute Idee, mal eine Spezifikation (oder einen Leitfaden) zu machen, wie ein "erweiterbares" Modul am schlausten gestaltet werden sollte.

[Luisehahne]

Hallo,

Ich denke ich werde die Arbeit von doc fortsetzen. Ich hoffe das ist in Ordnung Doc. Ich sehe da auch Handlungsbedarf, alles unter einen Hut zu bekommen.

Gruss
Dietmar

[Stefek]

Das wäre toll, Dietmar.

Gruß,
Stefek

[Luisehahne]

Das schafft man natürlich nicht alleine. Vielleicht gibt es ja noch Mitstreiter?

Gruss
Dietmar

[mr-fan]

@dietmar:

mal im französischen lager nachfragen der user Quinto (auch ein guter coder) hat sich glaub ich sehr intensiv an dem leitfaden orientiert als er einige module (user search...) angepasst bzw. umgeschrieben hatte

-für readme's usw. kann ich auch herhalten (wenn's dem ende zugeht) in ein bis zwei monaten hab ich wieder mehr luft

-für programmierer arbeit bin ich nicht hilfreich....

es gibt hier so viele gute programmierer bei WB - weis nicht ob es so schwierig ist sich auf einen gemeinsamen pfad/rahmen zu einigen und jeder sein spezialwissen dazu besteuert - glaub dadurch könnte die modulentwicklung nur gepuscht werden - und ich denke auch die Sicherheit würde sich dadurch verbessern! wenn WB mal ein wenig bekannter wird kann das auf alle fälle nie nicht schaden!

mfg martin

[Luisehahne]

Ja, wir sind ja international. Aber glaube mir WB ist sowas von bekannt (Dein letzter Absatz) Gib mal in Google WebsiteBaker ein. Habe ich heute morgen gemacht. Soviel Lob für WB geht runter wie Öl.

Gruss
Dietmar

[Stefek]

In letzter Zeit habe ich mit Thorn an einem Modul gearbeitet - er als Programmierer, ich als Designer.
Die Arbeit dauert noch an, bald wird das Modul zumindest vorgestellt (wir brauchen Übersetzer! - wer englisch versiert ist, bitte per PM an mich).

Warum schreibe ich das - weil ich große Lust hätte an dem Part für die "Richtlinien" für die Gestaltung der Module-Backends mitzuwirken.

Ich bin kein Coder - überhaupt nicht - deswegen kann ich bei den Sachen über OOP und die anderen "Fachbegriffe" nur unverständlich meine Stirn runzeln.
Aber bei Design sieht es schon ganz anders aus.
Und sind sich alle mal über solche Richtlinien einig, überarbeite ich das eine oder andere Modul, um es auf diesen Standard zu bringen.
Das ist dann zwar "nur" das Design, aber zumindest schon ein "stabiles Etwas" in dem Ganzen.

Ich habe sogar ein paar andere gute Ideen, wie man eine "Mannschaft" zusammenstellen könnte, die sich der Aufgabe gewidmet hat, Module auf einen Standard zu bringen. Aber dafür bedarf es eben solcher Richtlinien und mehrerer Freiwiliger, die es gerne tun.

In diesem Sinne,
Stefek

[Luisehahne]

Hallo Stefek,

nichts gegen dein Angagement, nur finde ich es seltsam, dass du dich erst ein paar Post später so reinhängen willst. nachdem  ich mich bereit erklärt habe dies weiterzuführen. Was sind die Gründe, dass du nach dem Ausstieg von Doc ( und das war am 22. April, jetzt ist der 9. Juli ) nicht direkt gesagt hast, du machst das weiter.

Du bist natürlich willkommen mitzuwirken und deine hervorragenden konstruktiven Wünsche loszulassen. Jetzt wird erstmal ein Anfang geschaffen, da ich mich in dieses Thema erstmal einarbeiten werde und schaue wo die Probleme liegen.

Arbeitet die Mannschaft nur für dich, oder können sich die User mal outen, wer bereit ist mitzuhelfen.

Dietmar

[Stefek]

Oh hallo Dietmar.

Nicht, dass ein Missverständnis aufkommt.

Ich habe keine Mannschaft, aber ich fände eine Überarbeitung vieler Module als wünschenswert und habe eine ungefähre Vorstellung, wie ein Team strukturiert werden könnte.
Aber zunächst müssten die Richtlinien kommen.

Ich finde es toll wenn Du es weiterführst und wenn dann der Schritt mit dem Design kommt, helfe ich gerne aus.

Wobei ich sagen muss, dass vieles was ich für WebsiteBaker vorhabe, davon abhängt, was sich nach dem Release von WB 2.8 ergibt.
Z.B. habe ich es völlig aufgegeben - fürs Erste - ein richtig ansehnliches Backend zu erstellen, obwohl ich von vielen Seiten darum gebeten wurde. Der Grund ist eben der, dass da - wie Du weißt - vieles noch gemacht werden muss.
Viel schlauer wäre es meiner Meinung nach gewesen, zunächst ein Theme zu machen, bis es wirklich ein reines Theme ist und von dort aus könnte man die 3 Themes integrieren, die im Bundle ausgeliefert werden.
Das reine Theme hätte von vornherein einiges an zusätzlichen CSS Klassen beinhalten können, die später von Developern für ihre Module verwendet werden können.
Zwar haben Module ihre eigenen CSS Files, sind sie aber tatsächlich erst dann nötig, wenn das Backend.css die erfordernisse nicht mehr deckt.

Jetzt werden wir viele bunte Smarties haben, die, wenn man umfangreiche Module hat, nicht mehr ins Design des Themes passen.

Ob das schlimm ist, weiß ich nicht, schön ist es aber nicht unbedingt.

Wie dem auch sei - das Backend Layout der Module geht zum Teil mit dem gesamten Theme Layout einher.

Aber wie auch schon öfter gesagt - kommt 2.8 und jQuery, werden wieder neue Dinge Eingang finden und ... soviel Zeit für ehrenamtliche Tätigkeit habe ich dann auch wieder nicht.
Aber hier und da gerne leiste ich eine helfende Hand.

Ich hoffe, dass es das Missverständnis auflöst.

LG,
Stefek

[Luisehahne]

Kurz und bündig, danke für deine Ausführungen, Missverständnis aufgeklärt. Packen wir es an und warten auf die Freigabe von 2.8 was nicht mehr lange dauern kann.

Alles weitere kann ja danach besprochen und geklärt werden. Ich greife dann hin und wieder gerne deine helfende Hand.

Gruss
Dietmar

[doc]

Hi,

Ich denke ich werde die Arbeit von doc fortsetzen. Ich hoffe das ist in Ordnung Doc.

Nur zu. meinen Segen hast Du (siehe thread "Module Primer, Modulleitfaden")

Das Module nun "Objektorientiert" programmiert sein müssen, halt ich nicht für zwingend notwendig. Ein Modul umbauen kann ich mit oder ohne OO, wenn ich es denn muss. Mir ist lieber ein sauber programmiertes Modul (prozedural oder modular) anzupassen, als ein schlecht geschriebenes Modul welches objektorientiert programmiert wurde. Denke PHP lässt den Programmieren die Freiheit zwischen verschiedenen Programmierparadigm en, das sollte man für Module beibehalten.

Viel wichtiger wäre es meiner Meinung nach den WB Core zu entrümpeln, Schnittstellen für Module zu schaffen. Wünschenswert fände ich, wenn z.B. ORM etc. Einzug in den WB Core halten würden, aber auch Geschichten wie CRUD würden helfen immer wieder duplizierten Code zu vermeiden.

Es gibt zuhauf gute freie CMS Implementierungen (nicht Joomla), bei denen man sich das ein oder andere Abschauen könnte. WB ist auch so beliebt, weil einfache Kenntnisse in PHP meist reichen, um Templates, Module ode auch das CMS selbst an die eigenen Wünsche anzupassen, ohne sich erst gross in ein Framework etc. einlesen zu müssen. Was den einen als Vorteil erscheint, ist für "ambitioniertere Anwender" dann bereits der Nachteil des Systems.

Doc

[chio]

Es wird immer so getan, als ob OOP ein besonderes Qualitätsmerkmal sei. Unhinterfragt.

Die allermeisten Aufgaben, die man mit PHP macht, haben prozeduralen Charakter: Etwas von vorne weg bis zum Ende abarbeiten und das Ergebnis bereitstellen. Fertig.
Das ist bei anderen Programmier/Scriptsprachen anders, etwa bei Javascript ist OOP sehr berechtigt; da kommt der Client/User ins Spiel und es gibt dadurch weit mehr Möglichkeiten, was ein Script am Ende tut.

Etwas, was ich nur 1-3 mal brauche, muss ich nicht kapseln. Da kommt meiner Meinung nach viel zu viel Overhead rein, der letztlich dazu führt, dass man sich für kleine Änderungen zuerst einmal tief einarbeiten muss.

Konkret gesagt:
Um bis 3 zu zählen kann ich: echo '1 - 2 - 3' hinschreiben.
Oder eine Repeat-Schleife machen, die dasselbe ausgibt.
Oder ein Objekt erzeugen, das initialisiert, ein anderes, das hochzählt, ein drittes, das ausgibt.

Und jetzt kommt das Argument: Aber Objekte sind so flexibel, damit kann ich auch bis 4 zählen! Ja stimmt. Das kann ich aber ohne Objekte auch. Und zwar weit durchschaubarer.

[Luisehahne]

Hallo Doc,

schön von dir zu hören.

Stimmt was du sagst. OPP muss nicht unbedingt sein. Hatte ich glaub ich aber auch schon geschrieben oder mich nicht klar ausgedrückt. Denke auch,  man muss da dem Modulprogrammierer die Freiheit lassen, sonst würden viele gute Module erst garnicht entstehen.

Beim entrümplen ist man schon fleissig dabei. Vieles hat sich im Laufe der Zeit geändert und da muss man sich heben halt anpassen. Warte mal auf die 2.8 da ist bereits einiges im validen HTML Bereich. CSS wird so schnell nicht möglich sein. Man validiert mit CSS 2.1 aber sämtliclhe Neu Entwicklungen arbeiten inzwischen mit CSS3 (siehe jquery). Auch das wird im Leitfaden mit berücksichtigt werden müssen.

Freue mich schon auf meine Arbeit. Soll ja auch Spass machen und hoffe, dass ich viel Unterstützung bekomme.

Bis denne man hört voneinander.

Dietmar

[Luisehahne]

Hallo Chio,

mein Post sollte eigentlich vor deinem rein. Damit haben sich deine Bendenken wegen OOP hoffentlich von alleine erledigt. Hatte mich wohl doch in den voriegen Post unklar ausgedrückt. Kein Zwang für OOP.

Man wird sehen was die Zukunft bringt. Wird sich eh alles einspielen

Danke trotzdem für deine konstrktive Kritik

Dietmar

[WebBird]

Mit OOP ist das wie mit vielen anderen Dingen auch: Es ist (oft) sinnvoll, vor allem bei großen Projekten, aber nicht immer und für alles.

Das richtige Werkzeug für den richtigen Zweck. Man schlägt ja auch nicht einen Nagel mit der Dampframme ein.

Aus Performance-Sicht ist z. B. auch zu bedenken, daß die Erzeugung und Zerstörung von Objekten einen Overhead darstellt. Bei der intensiver Vererbung muß der Interpreter die Hierarchie nach den Funktionen durchforsten, wenn diese in der vererbten Klasse nicht überschrieben wurden. Die Objekte und deren Verwaltung belegen Speicherplatz. Usw.

OOP ist 'ne feine Sache, aber nicht die Wunderwaffe für alles. Man muß schon genau überlegen, wo es sinnvoll ist und wo nicht.

[chio]

Als Copy&Paste PHPler kann ich Bedenken nur sehr bescheiden äußern, das ist mir schon klar.

Mir ist schon aufgefallen, dass die Begeisterung für OOP zunehmend wächst. Wohl deswegen, weil es jetzt mit PHP möglich ist.
In anderen Programmiersprachen, in den OOP schon länger üblich ist, hat sich die Begeisterung schon lange wieder normalisiert, es wird eben abgewägt, was sinnvoll und nötig ist.

Was ich einfach verhindern möchte: Dass hanebüchene kleine Module plötzlich mit Riesenframework daherkommen, um ein Feld in eine Datenbank zu schreiben und wieder auszulesen.
Und das natürlich nur mit dem neuesten PHP möglich, ohne Hinweis darauf.

Ein Modul sollte immer mit der niedrigsten PHP-Version laufen, die nötig ist.

[WebBird]

Das OOP aus PHP5 ist schon ganz nett, es gibt so einiges, was ich mir für Perl auch heiß und innig wünschen würde. Dafür ist anderes nicht so toll, etwa daß es keine multiple Vererbung gibt. (Wobei ich Leute gibt, die mich für diese Aussage lynchen werden. *g*)

Ansonsten ist die Lernschwelle für OOP vermutlich hoch genug, daß wir nicht fürchten müssen, daß jedes Mini-Modul zum Objekt-Klotz auswächst.