OOP / WB-Libs generell

[doc]

Hi,

Auffällig und Typisch:
Die bisher für WB verfügbaren "privaten" Libs decken die typischen Kernbereiche ab: 'Templates', 'Datenbankzugriff' und 'Mehrsprachigkeit'. Einige Lösungen erinnern etwas an PEAR, oder andere OS Libs.

Was wohl bedeutet, daß WB selber in diesen Bereichen nur unbefriedigende Lösungen bietet.

Yepp.

Doc

[chio]

installiere ich ein modul von webbird brauche ich wblib, installiere ich ein modul von ralf brauche ich rhtools und maybe noch das db packet. so habe ich nachher 5 module installiert obohl ich nur 2 installieren wollte.

Ja, das ist völlig blödsinnig. Man würde fast glauben, es ist eine Frage der Eitelkeit

Ich würde mir wünschen, dass ein Best Of in den Core kommt und was dann noch fehlt eben direkt in die jeweiligen Module.

[maverik]

Letztlich ist es Sache des Core-Teams, eine zentrale Lib zu bauen, die alle externen überflüssig macht. So lange es die nicht gibt, behalte ich mir vor, meine eigene zu benutzen.

Entschuldige bitte aber Du bist doch auch ein Mitglied des Core-Teams. Sollte es da nicht so sein das man im Team zusammenarbeitet, Ressourcen bündelt um das beste für das Projekt zu erreichen?

Ich bin da allerdings auch ganz egoistisch - ich entwickle wblib für mich.

So sind dann alle egoistisch und jeder entwickelt sich seinen eigenen websitebaker, ist das Teamarbeit die dem gesamten Projekt nützt?

Wie weit geht der eigene Egoismus irgendwann einmal? Gibt es dann WebsiteBaker Linie Entwickler A und WebsiteBaker Linie Entwickler B usw.. Muss der Anwender sich dann entscheiden welche Linie er fährt weil sonst Libs und Module ins Trudeln kommen.

In meinen Augen kann es das nicht sein und ist dem Projekt WebsiteBaker nicht dienlich, förderlich.

[maverik]

Das ist und war kein persönlicher Angriff. Es ist eine allgemeine Entwicklung bei websitebaker, respektive auch bei anderen Projekten im Netz zu beobachten, die mir aufstößt und Du hast es einfach klar ausgesprochen > Egoismus.

Egoismus und Teamarbeit sind aber zwei Dinge die, in meinen Augen, nicht zusammen passen. Das ist allgemein so und nicht persönlich zu nehmen.

[Waldschwein]

Hallo!

Wieso soll ein Teammitglied nicht so programmieren dürfen wie es will? Verstehe ich nicht.
Zudem: Bis WebsiteBaker neugeschrieben ist, vergeht das eine - vielleicht sogar das andere - Jahr. Und diese Zeit muss man eben überbrücken. Natürlich kann man auch den Riegel vorschieben und grundsätzlich sagen "wer mehr will als ein Gästebuch soll gefälligst zu ModX oder Typolight gehen, wir sind einfach". Letztendlich liegt es doch am Benutzer, was er selber will. Alternativ kann man natürlich eine halbfertige Library mal eben so aufnehmen - aber was dabei herauskommt sehen wir im Ansatz bei YUI. Oder bei HTMLarea damals.

Gruß Michael

[Stefek]

Ich glaube, Bianca meinte mit "egoismus", eher einen privaten Vorzug, als dass sie das nur und ausschließlich für sich macht.
Man muss das halt vom praktischen Gesichtspunkt eines Coders aus sehen.
Die internen Möglichkeiten von WB sind eingeschränkt und diese "persönlichen" Libs ermöglichen es den Codern bestimmte Aufgaben so auszulagern, dass sie in verschiedenen Projekten eingesetzt werden können.
Das finde ich an sich eine vernünftige Sache.
Und es macht eigentlich nichts aus, wenn ich ein bestimmtes Modul installieren will, das eine zusätzliche Installation erfordert, dann mache ich es dann  - es  ist immer noch besser, als völlig auf das Modul zu verzichten.

Auf die verschiedenen "Strömungen" der Coder habe ich vor über 1,5 Jahren hingewiesen - haha, da habe ich mir Gott weiß keine Freunde mit gemacht. Es hat sogar viel Anlaß für Fehlinterpretatione n und Schuldzuweisung gegeben.
Aber da siehr man, wie richtig ich lag.

Ich wll jetzt hier aber auch nicht andeuten welche der Libs "die Beste" ist, oder dass die anderen für die Mülltonne sind.
Fakt ist, dass phpLib nicht viel mehr macht als die Templates. In einer sehr komplizierten Art.

Die wbLib habe ich mir nicht genau angeschaut.
Das PMF Paket habe ich mir angeschaut und vor allem im Bereich der Templates und Sprache hat es großen Eindruck auf mich gemacht.

Dieses "seltsame" {{_pmf_t('Sorting')}} gegenüber einem vermeintlich "einfacherem" {{ Sorting }} ist leicht erklärt und verstanden.
PMF arbeitet mit PHP - es ist nichts anderes als PHP, wie man auf der "Introduction" Seite nachlesen kann.
Ein zusätzlicher Vorteil für den Designer hierbei ist, dass er sich auf einfachem "Niveau" mit PHP auseinander setzt und so auch problemlos an PHP herangeführt wird.
Bei phpLib muss der Coder "geistige" Verrenkungen machen, um es dem Designer zu ermöglichen, ein Template zu erstellen.
Anders bei PMF. Gradlinig und einfach.

Ich würde mir wünschen, dass ein Best Of in den Core kommt und was dann noch fehlt eben direkt in die jeweiligen Module.

Das würde ich mir auch wünschen.
Aber wer soll das entscheiden?

Stefek

[doc]

Hi,

denke eine WBLib, welche mit dem CMS ausgeliefert wird macht durchaus Sinn. Am besten eine Kombination der besten bereits vorhandenen Ansätze in eine gemeinsame WBLib überführen.

Eine Neuauflage des WB Kerns (WB 3.0 oder "Next Generation") geht warscheinlich mit dem Verlust der Abwärtskompatibilität der Module und Templates einher. Wird sich erst noch zeigen müssen, ob für diese Version dann bestehende Module portiert werden können und auch werden, was wiederum die Akzeptanz und den Erfolg dieser neuen WB Generation ausmacht.

Ne vernünftige WBLib als Hilfsmittel für Modul- und Templateentwickler in der "nächsten WB Generation" macht wohl am meisten Sinn.

Doc

[Waldschwein]

Hallo!

Sinn macht vor allem in der nächsten Generation das, was generell heutzutage Stand der Dinge ist: MVC in Verbindung eines Frameworks, worauf WB nur noch basiert.
WB 2.x ist einfach, aber das einfache ist halt überall, und daher wird es relativ schwer (z.B. im Vergleich zu den neueren CMS-Systemen) auch einmal etwas größeres zu realisieren, oder Änderungen an WB zu machen. Man muss in vielen Bereichen direkt in den Core-Files herumfurwerken. Aber da ist der Ansatz einiger Libs sicherlich nicht schlecht.

Dass Module und Templates in der Next Generation nicht mehr funktionieren sollte sich von selbst verstehen. Man darf ja auch nicht verheimlichen, dass der Grund von WB es war, eine Schulseite vor 5 Jahren zu gestalten, und man hat halt vieles erweitert und neu geschrieben, aber die Art des Cores ist gleichgeblieben...

Gruß Michael

[erpe]

Also ich habe Maverick etwas anders verstanden:

Es geht ihm überhaupt nicht darum, einem Entwickler zu verbieten, seine eigenen Projekte zu starten.
Aber natürlich erweckt die "Häufunng" von Libs schon irgendwie den Anschein, dass jeder sein eigenes Süppchen kochen will, weil er die Suppe des anderen nicht mag.

Und da muss ja auch mal die Frage von Nicht-Codern erlaubt sein (ausser Stefek  ), ob es nicht sinnvoller wäre, die Kräfte zu bündeln.

Ich denke aber auch, dass Bianka mit der Erklärung zu WB 2 und WB next generation schon die entsprechende Erklärung mitgeliefert hat.

Und dass da etwas in der Zukunft zusammengeführt wird, wenn die Leute alle an einem Tisch sitzen (Core-Dev), davon gehe ich einfach mal aus.

Und so müssen sich solche Sachen wohl im wahrsten Sinne des Wortes erstmal entwickeln.

In diesem Sinne.

erpe

[Hans>NULL]

@WebBird

Ich kleb den Keller meines Hauses ja auch nicht aus den Bruchstücken zerfallener Häuser zusammen.

Du könntest Dir doch 'nen Namen als Trümmerfrau der neuen Generation machen    
Grüatziliiiiiii, Hansi

[Stefek]

Und da muss ja auch mal die Frage von Nicht-Codern erlaubt sein (ausser Stefek  ), ob es nicht sinnvoller wäre, die Kräfte zu bündeln.

Waa?

Aber nein, ich sehe es genau wie Du und Bianka.
Ich bewundere Biankas Arbeit auf jeden Fall.
Ich bewundere auch total die Arbeit von Thorn und wie es der Zufall so will, habe ich mit ihm engeren Kontakt und ein wenig Einblick in seine gradlinige Arbeitsweise.
Womit ich aber nicht sagen will, dass nicht andere auch gradlinig arbeiten.

Natürlich sollte es zu mehr Austausch unter den Codern kommen.
Denn nur so, kommt auch ein Produkt bei raus, mit dem alle übereinstimmen können.
Ich denke eine gemeinsame Basis mit einigen "individuellen Abstrichen" ist immer noch besser als überhaupt keine Einigung.

Selbst bei OOP gehen die Meinungen in viele Richtugen.
Ich weiß nicht, ob Chio Lust hat, seine Programme auf OOP umzustellen, oder mit OOP zu programmieren.
Ich sicher nicht.
Daher denke ich, dass hier und da einige Leute vorm Kopf gestoßen werden -  zu Unrecht.

Ich denke mittlerweile gibt es um WB herum ziemlich gute Coder (mehr als noch vor 2 Jahren). Eine gute Anzhal von guten Codern.
Wenn ich auch nicht behaupte, dass man gänzlich ohne OOP auskommt, so bin ich aber dennoch der Meinung, dass auch für später noch die Möglichkeit bestehen sollte, für WB in der "traditionellen Manier" zu programmieren - eine Richtung, die Thorn verfolgt (und ich glaube nicht, dass es aus Unvermögen, sondern eher aus dem Motiv heraus ist, WB auch für PHP Laien weiterhin zugänglich (verständlich) zu belassen, sodass sie immer noch was damit anfangen können).

Das ist an sich eine "ehrenvolle Angelegenheit".

Aus der ganzen Debatte ist ja auch herauszuhören, dass die "Richtung" noch nicht festgelegt wurde.
Und wie es mich dünkt, sieht es so aus, dass dann der Mann der am weitesten oben sitzt, die Beschlüße macht, statt einer Gruppe von Leuten, die sich mit der ganzen Problematik persönlich auseinander gesetzt hat.
Das ist schade, und hat in der Vergangenheit auch immer wieder für Verwirrung gesorgt - siehe Backend Themes. Eine gute Idee, die aber nicht zu Ende gedacht wurde und jetzt viel zu viel Aufmerksamkeit erfordert.

Neue Lib, braucht man das?
Nun ja, kommt ganz drauf an, was für WB geplant ist, wer es plant und wer die Entscheidungen trifft.
Auf individueller Basis kann ja jeder seine Lieblings-Lib verwenden, aber was kommt denn da in den Core?
Dass phpLib überholt ist, ist keine Frage mehr.

Stefek

[maverik]

Also ich habe Maverick etwas anders verstanden:

Es geht ihm überhaupt nicht darum, einem Entwickler zu verbieten, seine eigenen Projekte zu starten.

Immerhin, einer hat es verstanden.

niemand hat das Recht, einen Entwickler auf WB zu reduzieren

Das Recht nehme ich mir auch nicht heraus und so war es, wie erpe richtig erkannt hat, nicht gemeint.

wer anderen Egoismus vorwirft

Auch das ist in den falschen Hals gekommen. Von Egoismus hat Du Webbird gesprochen bzw. den Begriff in die Runde geworfen.

Ich bin da allerdings auch ganz egoistisch

Und zur Stichelei sei soviel gesagt das dass Tut-Projekt privat ist und meine Seite ist auch privat.


Das man / jeder aus privaten Entwicklungen lernt steht ausser Frage. Nur wenn jetzt schon von verschiedenen Leuten in verschiedene Richtungen entwickelt wird und diese Entwicklungen öffentlich einfließen wieso soll das dann später auf einmal zusammen funktionieren? Heißt es dann WB 2 war ein Versuchsballon den wir jetzt einstampfen und die ganzen damit gemachten Erfahrungen gebündelt in WB 3 einsetzen?

WB 2 wird damit zum Chaos CMS.

Dann sollte WB 2 lieber einen "Feature Freeze" haben, das vorhandene in Ordnung gebracht und ansonsten zum Auslaufmodell erklärt werden. Weitere Entwicklungen nur noch unter den Core Mitgliedern besprochen und getestet werden so dass dann die gemachten Erfahrungen und Entwicklungen gebündelt mit der 3 oder next generation veröffentlicht werden.

[erpe]

Also dass WB 2 ein Auslaufmodell ist, das ist doch selbst schon zu Zeiten von Ryan dargelegt worden.
Aber eben auch, dass es nicht von heute auf morgen einen Umstieg in eine neue Generation von WB geben kann, sondern dass dieser Übergang fliessend sein muss/wird.

Aber alten Wein in neue Flaschen abzufüllen macht ja auch wenig Sinn.
Deswegen sitzen doch auch schon eine Reihe von Leuten daran, sich über das "wie" Gedanken zu machen.

Wenn es dann etwas zu berichten gibt, werden sie das schon tun.

Bis dahin wird es wohl kein Feature-Freeze geben, aber ich persönlich kann mir auch nicht vorstellen, dass jetzt noch ganz aufwändige Feature in WB2 reingecodet werden.

Gruss

erpe

[Waldschwein]

Hallo!

Ich bin stattdessen dafür, dass http://nettest.thekk.de/docs/wysiwyg_history/files/naturaldocs_txt/title-txt.html in 2.8.2 Einzug hält im Core!

So, etwas aufbauendes gesagt. 

Gruß Michael

[Stefek]

Hmm...

Kann es sein, dass dies:

Deswegen sitzen doch auch schon eine Reihe von Leuten daran, sich über das "wie" Gedanken zu machen.

das:

Und wie es mich dünkt, sieht es so aus, dass dann der Mann der am weitesten oben sitzt, die Beschlüße macht, statt einer Gruppe von Leuten, die sich mit der ganzen Problematik persönlich auseinander gesetzt hat.

bestätigt?

Das ist schade, und hat in der Vergangenheit auch immer wieder für Verwirrung gesorgt - siehe Backend Themes. Eine gute Idee, die aber nicht zu Ende gedacht wurde und jetzt viel zu viel Aufmerksamkeit erfordert.

Stefek

[Waldschwein]

Hallo!

Wenn einer beschließt geschieht wenigstens etwas. Selbst im Kommunismus war immer einer oben gestanden und hat beschlossen, was die andren zu tun haben. 
Und: Ich denke kaum, dass einer Beschlüsse gegen andere macht. Es muss nur koordiniert werden, und ohne Koordination kommt erst einmal gar nichts raus.
Und Backend-Themes war doch eine gute Sache. Immerhin hat der Markt eines der Themes bestätigt. Lieber machen. 

Gruß Michael

[Stefek]

Das zeigt mal wieder, dass Du keine Ahnung hast, weil Du WB nur oberflächlich einsetzt.

Und Kommunismus war KEINE gute Sache, nicht einmal im Ansatz.
Wäre es so, würden die Länder, die ihn praktizierten nicht völlig verarmt, wie sie es sind.

Also Genoße, wenn Du schon auf meinen Beitrag antwortest, dann verstehe ihn zumindest zuerst, bevor Du postest.

Niemand sagt irgendetwas, dass man ohne Beschlüße handeln soll.
Aber wenn sich 20 Leute Kopf gemacht haben, dann kann es nicht sein, dass da Vetternwirtschaft praktiziert wird, oder Guruismus. Oder "besser ein Beschluß, als eine Evaluation."

Die Backend Themes sind ein Fliegenschiß gegen dem Potenzial, das in ihnen steckt.

[erpe]

Hmm...

Kann es sein, dass dies:
Zitat von: erpe am Heute um 14:37:30
Deswegen sitzen doch auch schon eine Reihe von Leuten daran, sich über das "wie" Gedanken zu machen.

das:
Zitat von: Stefek am Heute um 14:16:57
Und wie es mich dünkt, sieht es so aus, dass dann der Mann der am weitesten oben sitzt, die Beschlüße macht, statt einer Gruppe von Leuten, die sich mit der ganzen Problematik persönlich auseinander gesetzt hat.
bestätigt?

Zitat
Das ist schade, und hat in der Vergangenheit auch immer wieder für Verwirrung gesorgt - siehe Backend Themes. Eine gute Idee, die aber nicht zu Ende gedacht wurde und jetzt viel zu viel Aufmerksamkeit erfordert.

Stefek

@Stefek:
verstehe ich nicht, wen oder was meinst du denn damit?

Gruss

erpe

[chio]

Selbst bei OOP gehen die Meinungen in viele Richtugen.
Ich weiß nicht, ob Chio Lust hat, seine Programme auf OOP umzustellen, oder mit OOP zu programmieren.

Ich programmiere mit OOP - wenn in einem Spiel  ein Wägelchen 200 Kugeln sammeln soll. Dann ruft jedes Kugel-Objekt seine Methoden 40x pro Sekunde auf, stundenlang.

Aber nicht bei einem Script, das in 1/10 Sekunde jedes erzeugte Objekt gerade 1x braucht, da fehlt mir echt das Verständnis dafür.
Dafür wir alles völlig unübersichtlich.

[Stefek]

@Chio.
Danke, dass Du darauf geantwortet hast. Sowas habe ich mir schon gedacht - ich kenne ja auch Dein Shockwave (Director?) Game - klar, da ist die Sache mit OOP sehr Sinnvoll und unumgänglich.


@Erpe,
ich meine tatsächlich, dass es schade wäre, wenn jetzt die vielen Lösungen irgendwie an der Entscheidung über die weitere Entwicklung vorbeigingen.
Das sollte keine "Beschuldigung", sondern eine Frage sein.
Fakt ist, Thorn war vor langer Zeit im Core Team und wir habn ihm ganz tolle Sachen zu verdanken, die fester Bestandteil de COREs geworden sind.
Dass er für OOP nicht entwickeln will, sagte er ja bereits öffentlich vor etwas über einem Jahr.
Was seine Einstellung gegenwärtig ist, das weiß ich nicht - aber sooo viel wird sich da eher nicht geändert haben (sorry Thorn, ich will nicht wirklich für Dich sprechen, ich mutmaße nur.)

Was ich meine ist, es wäre gut, wenn die Developer auch diese Ideen berücksichtigten, sodass wirklich eine gute Entscheidung getroffen werden kann.
Für einige ist OOP das Maß aller Dinge, für andere nicht.

Das "Wohl" des Jägers, ist nicht das "Wohl" der Ente. Klar.
Und ich denke, wenn WB weiterhin unter dem Banner "Einfaches CMS" stehen soll, dann verfehlt man einfach den Zweck, wenn man nur und auschleßlich auf OOP setzt.

Da jetzt vieles hinter verschloßener Tür geschieht, kann man nur spekulieren (und alles bisher waren Spekulationen).
Die Debatte dreht sich hauptsächlich um eine geeignete Lib und die verschiedenen Ansätze.
Doc hat sie alle aufgeführt in einem der obigen Posts (oder war es im EN Thread? whatever).

Es geht einfach um die Berücksichtigung der Ideen anderer erfahrener Coder.
Für mich zählen Bianka, Thorn, Christian(doc), Ralf, Ruud, John (PCWacht), Werner (DarkViper), Michael (BlackTiger), Aldus dazu (Reihenfolge zufällig) (falls ich jemanden nicht aufgeführt habe, entschuldigt).
Es gibt wohl noch andere, aber das sind die, von denen ich weiß, dass sie RICHTIG coden können.
Dann gibts dadrunter welche, die sehr gerne OOP einsetzen würden, einige, die darauf als das NON Plus Ultra schwören und einige, die größtenteils darauf verzichten würden/könnte bzw. es nur "delikat" einsetzen würden.
Dann gibt es noch Coder wie Chio, die wertvolle Beiträge haben, die sich aber mit der Selbstbezeichnung "Programmierer" etwas zurückhalten. Davon gibt es schon mehrere.
Dann gibt es völlige Laien, die ein wenig was basteln können, ein paar DB Queries machen können, um Module anzupassen oder nur kleine Module zu machen imstande sind (dazu würde ich mich zählen).
Wenn auch die zuerst genannte Gruppe aus wirklich guten Codern besteht, darf man die anderen Gruppen nicht vernachläßigen, weil wenn die "Benutzung" einfach ist, aber das Bereitstellen von Erweiterungen nicht, wird das CMS "einfach", aber "klein" (nicht erweitert) bleiben.

Na, Du siehts worauf ich hiaus will.
Die Sache ist nicht so einfach, wie man denkt.
Man muss halt eben auch an die andern denken, nicht nur an das Dev Team bzw. eine kleine Gruppe, die "genial programmieren" kann.

Gruß,
Stefek

[erpe]

Doch, für mich ist die Sache ganz einfach.

Die meisten von dir genannten sind in die WB Core Entwicklung involviert.
Und dort wird über den Core (und nur Core) geredet.
Und wenn dort entschieden wird (was ich nicht weiss), dass nur OOP gecodet wird (auch das weiss ich nicht), dann werden die sicherlich gute Gründe dafür haben.
Und wenn Thorn sich entscheidet, nicht OOP zu machen, hat er auch gute Gründe.
Und wenn er sich dann entscheidet, nicht am Core Development teilzunehmen, ist das aus meiner Sicht auch völlig ok.
Und wenn er dann etwas zur Verfügung stellt, was von jedem (nach Installation) zusätzlich genutzt werden kann, ist das doch bestens.

Und wenn sich dann irgendwann Entscheidungen aus dem DEV-Team zeitlich (oder aus anderen Gründen) überholt haben (siehe php4 || php5, dann muss es eben geändert werden.
Ich sehe da gar kein Problem.
Wenn ich xfast_Template nutzen will, muss ich eben ein paar Module extra installieren (schön, wenn man schnell sehen kann, welche denn....).
Wenn ich das nicht will, lasse ich es eben und kann xfast_template nicht nutzen.

Ich persönlich denke, im Core darf nur soviel wie nötig sein, damit die Maschine läuft (incl ein paar Standard-Dinge).
Und alles andere hole ich mir entsprechend dazu, wie ich es brauche.

Die Bereitstellung von libs über Module ist doch so schnell und einfach..........

Und wie du  schon selbst sagst: Zusatzmodule werden eben manchmal später irgendwie Core (siehe SM_2. Droplets, usw).


Gruss

erpe

[erpe]

Genauso meinte ich es eigentlich auch.

Aber du hast schon recht.

Hier sollten nicht mehrere Einäugige (meine damit mich und andere Nicht-Coder) über das Farbfernsehen reden.

Ihr macht das schon.

Gruss

erpe

[Stefek]

Vielen Dank Erpe und Bianka.

Nein, nein.
Durcheinander gebracht habe ich es jetzt aber nicht.
Ich weiß schon, dass man auch dann noch prozedural geschriebene Programme einbinden kann (Module, Snippets etc.)

Die von Erpe genannten Argumente sind nicht anfechtbar und logisch.
Bleibt nur zu hoffen, dass egal wie die Entscheidungen ausfallen, die phpLib "rausgeklopft" und durch etwas logisches ersetzt wird.
Die Backend themes laufen heute mit der phpLib, wie auch viele der Module (AFE ja auch, wenn ich nicht irre).
Es gibt auch nicht viel gegen phpLib einzuwenden, dort wo sie eingesetzt wurden, funktionieren sie ja auch - aber fragt mal die Coder nach dem nötigen Aufwand.

Dass sowas mit Biankas Lib einfacher geht (hat ja auch eine logische template engine) bezweifle ich nicht - bin ich mir sicher.
Ob sie an die Einfachheit von PMFs Methode herankommt, das müßte sie selbst dann anschauen, wenn sie dann da Lust zu hat.

Also braucht man noch eine Lib?
Irgendwann fürs Core muss was geeigneteres rein, was nicht nur das Backend Theme, sondern auch die Modulentwicklung vereinfacht (backend templates und die gewöhnlich unter Optionen zu findenden Layout-Fields (Loops etc..).

Wenn es da was übergeordnetes gibt, womit Leute übereinstimmen können, ist doch super.
Es geht mir jetzt nicht darum, dass durch eine CoreLib keine anderen Libs mehr verwendet werden dürfen, sollen, oder dass jemandem ein Maulkorb umgehängt werden sollte
Ich will einfach nur andeuten, dass die phpLib mal gecancelt werden sollte, es auch sicherlich wird und da wäre es gut, wenn sich die bereits "tummelnden" Libs auf Pro und Contra hin überprüft würden.

Das war so in Etwa meine Aussage.

Und klar, ich bin auch der Meinung, dass der CORE und auch die ausgelieferte Basis Version so klein wie möglich gehalten werden sollte.
Solange man nicht die Ohren wegrasiert, dürfen alle Stoppeln wech..  

Gruß,
Stefek

[Stefek]

Hier sollten nicht mehrere Einäugige (meine damit mich und andere Nicht-Coder) über das Farbfernsehen reden.

Irgendwas gegen mein "drittes Auge"? 

[chio]

Noch ein bissel mehr Senf von mir, ich bin gestern unterbrochen worden (Kundengfraster...)

Ich habe nichts gegen OOP, aber bitte dort, wo es hingehört. Nur um Sports wegen - "Ich will jetzt ein _richtiger_ Programmierer sein..) - das hift niemanden.
Ähnliches gilt für die diversen Libs.

Wenn der Code so zerfleddert ist, dass man nicht mehr nachvollziehen kann, was da eigentlich passiert, dann ist ein Modul reif fürs Sterbebett. Mag sein, dass der/die Entwickler zum Zeitpunkt der Erstellung noch gut im Kopf haben, welchen Segen die diversen Funktionen bringen - aber nach 3 Monaten können sich die oft selbst nicht mehr erinnern. Geschweige denn jemand, der eine Änderung daran machen will.

Wenn ich page_content()  in einer Variable haben will, dann nehme ich ganz einfach ob_start/ob_end. Ein Blinder mit Krückstock sieht dann, was da passiert. Stattdessen die Methoden irgendwelcher Objekte anzuzapfen? ISt das schlau - und "einfach"?

Der Code ist nicht schneller, nur weil er weniger Zeilen enthält. Man muss schon schon auf die Gesamtheit achten und auf den Overhead, den manche eierlegenden Wollmilchsäue mitbringen.

Nochmal: Ich habe nicht grundsätzlich was gegen OOP oder Libs, man muss sich aber genau anschauen, wo das Sinn macht.
Wenn man sich diesen Thread hier ansieht, merkt man aber gleich, dass das Thema viel mit Eitelkeiten und persönlichen Vorlieben zu tun hat, und das halte ich für keine gute Voraussetzung, um grundsätzliche Entscheidungen zu treffen.

Übrigens: Was ich mir wünschen würde:
Eine einfache Möglichkeit, von einem Modul aus Bilder hochzuladen. Derzeit macht das jedes Modul (mit Bildupload) selbst und ich bin mir nicht sicher, ob da nicht Sicherheitslücken von einem zum anderen kopiert werden.

PS: Falls jemand glaubt, ich darf da gar nicht mitreden, weil ich kaum PHP kann: Stimmt, PHP ist nicht so meins. Und wie die Dinger alle heißen (Methoden, Callbacks usw), weiß ich _auch_ nicht so genau, weil das in Shockwave alles anders heißt, aber wohl dasselbe ist.