OOP / WB-Libs generell

[chio]

Nach deinem Beispiel ist OOP aber reichlich aufgebläht.

derzeit brauchst du nur eine info.php und eine
view.php:
<?php echo 'Hello World'; ?>

DAS ist einfach!

Die ganze Logik, die in einem Modul steckt (Datenbank rein, raus, darstellung) wird ja wohl durch OOP nicht weniger.

Nachtrag:

Wenn ich eine "Codewurst" (passender Ausdruck...) ändern will, bleibt mir nichts anderes übrig, als eine neue Codewurst zu schreiben oder im Original herumzufuhrwerken (was nebenbei nicht der Sinn von Open Source ist).

Bei OOP überschreibe ich das entsprechende Objekt, füge die Funktion mit der gewünschten Funktionalität ein und fertig.

Nehmen wir zb topics/view.php als Beispiel. Das ist eine Codewurst.
Wenn du da jetzt einen Bug drin finden würdest, würdest du nicht den Bug ausbessern, sondern die ganze view.php ändern? Oder mit einer Instanz des Objekts den Bug überschreiben? Das würdest du für einfacher halten?
Oder würdest du generell sagen, Topics taugt nichts (ist ja nicht OOP), ich mach das gleich neu, und nenne es TopicsOOP?

Das wäre das, was ich mit "Doppelgleisigkeit  und Wildwuchs" meine.

[Waldschwein]

Datenbank rein, raus, darstellung

Ich hoffe ja stark, dass das mit dem neuen WB nicht mehr sein muss. Weil dann würde Datenbank-Abstraktion (MySQL verliert immer mehr Argumente gegen andere Datenbanksysteme, PDO ist ja fast schon Pflicht, solange man überhaupt noch PHP einsetzt...) wesentlich effizienter gehen. Und MVC / Framework ist ja auch ein Stichwort...

Gruß Michael

Edit: Was ist bitte überhaupt so schlimm an OOP? Wer es einsetzt tut es halt, wer es nicht will lässt es bleiben. Es gibt doch nirgends einen Guide / Anweisung / technische Geschichte "Du machst kein OOP, you're fired!".
Die Art der Programmierung ist doch den zugrundeliegendem System schnurzpiepsegal - wenn man die Daten richtig übermittelt (API ist ja immermal wieder ein Stichwort) kann programmiert sein wie man lustig ist. Oder sind Windows-Programme ausschließlich mit C# und .NET entwickelt? Nö, nur weil Windows .NET / DirectX bevorzugt, kann der Programmierer immernoch sein Spiel in Java oder C mit OpenGL schreiben - der API ist's ja recht egal. Seit doch nicht grundsätzlich dagegen, weil etwas neues kommt - aber seit auch nicht grundsätzlich der Meinung, neue Besen kehren gut.

[Waldschwein]

So, mir liegt es auf der Zunge, ich will einmal versuchen als Nicht-PHP-Versteher zu erklären, was überhaupt der Sinn und Zweck von OOP ist, das weiß ja keiner.

Bisher funktioniert unsere virtuelle Kaffeemaschine á la Topics so (ich versuche es zu erklären, ich liege bestimmt falsch, weil ich die Logik von Programmierung nur unter OOP nachvollziehen kann):

Beim Beitragserstellen gibt's die add.phps. Diese bringen alles mit was benötigt wird, und "bereiten" einen neuen Beitrag vor. Beim Kommentarerstellen gibt's die comment.phps. Diese bringen alles mit was benötigt wird,und "bereiten" einen neuen Kommentar vor.
Für das Ändern von Kommentaren / Beiträgen / Einstellungen gibt es die modify.phps. Auch diese bereiten das Ändern vor.

Dann werden die ganzen "Vorbereitungen" an die save.phps weitergegeben, die validieren das eingegebene und speichern es dann endgültig ab.

Letztendlich kommen die view.phps, und geben es aus.


Unter OOP mit gescheiter Unterstützung seitens WB (!!!!) sieht es folgendermaßen aus. Ich beschränke mic hmal auf MVC.
Einschub: OOP macht wenig Sinn, wenn man für jedes Add-on alles selber mitbringen muss. OOP ist nur sinnvoll, wenn es Systemweite Unterstützung seitens WB (und/oder Framework) gibt. Begriffe wie Klasse & Objekt setze ich natürlich vorraus.

WB / Framework bietet folgende API-Klassen: Erstellung einer Seite, Einstellungsänderungen.
Das ist das Rohgerüst, der Bilderrahmen.

Diese API-Klassen liegen "Abstrahiert" vorhanden, das heißt alles kann zugreifen darauf, und es werden unnötige Geschichten einfach weggelassen. Diese Erweiterungen kann jedes Modul selbst vornehmen.

Beim Beitragserstellen gibt es die add.php, die sich an die "Erstellung einer Seite"-Klasse andockt, diese erweitert um notwendige Dinge (z.B. Suchmaschinengeschi chten).
Beim Kommentarerstellen gibt es die comment.php, die sich an die "Erstellung einer Seite"-Klasse andockt, sich dazu die "Captcha"-Klasse holt für die Frontendsicherheit, dazu dann die "Frontend-Writing"-Klasse, und diese erweitert um notwendige Dinge (z.B. "Bewerte den Topic").
HÄ?
Ja genau. Jetzt wird die Erstellung einer Seite Klasse schon zweimal benutzt. Ist ja dasselbe, ob ein Kommentar oder ein Topic erstellt wird. Will man den Beitrag im Frontend von Gästen erstellen lassen, wäre es nach diesem Schema ein leichtes, das zu bewerkstelligen wie man sieht.

Diese vorhanden "Vorbereitungen" werden jetzt an den Controller weitergegeben, der in WB sitzt. Der Validiert lediglich und gibt dann die vorhanden "Benutzer-/Admin-Änderungen" von oben an die dazugehörige Klasse im Modell weiter.

Das Modell "sitzt" auf den ganzen Klassen, bekommt vom Controller die Anweisung "Hey, rück mal die Erstellung-einer-Seite Klasse raus". Und dann geht alles wieder "zurück" zur Anfänglichen "Präsentation (View)" die oben schon alles gemacht hat. Die view zeigt also nicht nur an, sondern agiert auch - als einziges der drei Systeme! - mit Benutzer / Admin.

Vorteile - schon allein wegen der Sicherheit und der Erweiterbarkeit - muss man nicht erst aufzählen.

Ist Topics wie es ist also schlecht? Nö. Ist Topics in OOP besser? Nein. Es ist erst dann "besser" in OOP, wenn WB die nötigen Geschichten alle mitliefert. Das ganze Herumhantieren mit Libs ist auch nur - man sieht es hier denke ich - deswegen so ausgebrochen, weil man versucht, OOP zu programmieren, aber WB es nicht wirklich zulässt.
Momentan bin ich aber der Meinung, dass Topics "wie es ist" am Besten ist, würde in OOP wohl (s.o.) gar nicht einmal so viel Sinn machen.

Wenn (wenn!) eine Gescheite API vorhanden ist, muss natürlich Topics nicht "class xy extend bla" verwenden. Dann kann man auch einen einfachen Array - wie sie ja haufenweise vorhanden sind in WB - dafür benutzen, und kann weiterhin nicht-OOP programmieren, wenn einem danach ist.

Ich hoffe, es ist halbwegs rübergekommen, und ich bin nicht ganz vorbeigeschrammt. Wenn jemand was zu motzen hat bitte kein "OMG u b00n, ich kanns besser" sondern gleich die Korrektur mitliefern, dann hat jeder was davon.

Gruß Michael

[chio]

Ich sags mal so:

Ich nehme WB deswegen, weil alles sehr _direkt_ und dadurch einfach funktioniert.

Ohne vorher das dicke Typoscript/Smarty/sonstwas-Buch auswendig zu lernen, kann ich ganz einfach im Template php reinschreiben und damit Funktionen erreichen, die ich gerade mal brauche.
Wenn ich was nicht weiß, kann ich einfach danach googeln und finde massenweise griffbereite Schnippel.
Und wenn ich ein bestimmtes Modul brauche, geht das so ähnlich: Zusammensuchen, schauen, verstehen, machen.

Sobald Libs im Spiel sind, ist es damit vorbei. Ich finde kaum mehr was mit Google, ich muss mir alles zusammenkratzen. Die Libs sind oft kaum dokumentiert und haben alle ihre eigenen Fallstricke.
Statt
if($_GET['wutzfutz'] == 'futz')
habe ich die tolle erleichterung:
if {:! ??'wutzfutz'% {"== 'wutz}[:][:]}
Welch ein Fortschritt...
Was ist schlecht daran, wenn im Template PHP verwendet wird?

Wenn ich sowas haben will, dann nehme ich ein CMS wo das so ist. Typo3 zb. Hmm ... muss ich mich mal umsehen.

-----

Upps... Das habe ich parallel zu michael geschrieben.

Mir kommt dies ganze Geschichte so vor:

Wir bauen in WB ein riesiges Schweizer Taschenmesser ein, mit Presslufthammer und allem dran, und dann nehmen wird nicht mehr schnell den Schraubenzieher aus der Werkzeugkiste, sondern klappen den Universal-Schraubenausmitnehmer unter dem Schlagteilexpander aus.

eine normale add.php besteht aus kaum mehr als einer auflistung der Felder, die vorbelegt werden sollen.
Will jemand im Ernst behaupten, dass man sich das erspart, wenn man OOP oder Frameworks verwendet? Woher wissen die denn, was einzufügen ist? Genauso: Man schreibt es hin, wie sonst auch.
Was macht denn eine modify.php? da macht sie eine Liste, dort irgendwelche Felder.
save.php: Checken obs passt, in die Datenbank schreiben. OK, das "in die Datenbank schreiben" kann man anders machen, aber letztlich muss ich sagen: $dings muss > 0 sein, $dongs ist ein string. Nimm die 2 werte und steck sie da rein.
Das, was man bei Modulen "allgemein" halten kann, sind da wie dort ein paar Zeilen. Der rest ist in jedem Modul individuell.

[Waldschwein]

Hallo!

Ich halte dagegen: Bisher gibt es geschätzte 15 _wirklich_ verschiedene Module für WB. Alle bauen irgendwie auf einem auf, das sich durchgesetzt hat. MPForm ist eine Erweiterung zu FormX was eine Erweiterung von Form ist. Calendar XY baut auf Calendar X auf, und Bildergalerie AB auf Galerie A, usw.
Das Ganze hat einen riesigen Nachteil: Hat Form einen Fehler, hat ihm FormX, hat ihn MPForm.
Das ist _nicht_ benutzerfreundlich.
Jeder holt sich hier und da Snippets zusammen, und am Ende ist jedes Modul mit jedem irgendwie verbunden.
Wenn man aber zentral alles in WB konsequent umsetzt, hätte man das ganze herumgefuhrwerke und herumgefrickle nicht.
Denn eines ist sicher: Ein bißchen MVC, ein bißchen OOP geht nicht, dann kann man es sicher sparen. Entweder 100% oder gar nicht - im Kern.
Die Sache wegen Smarty & Co. KG: PHPlib ist ein kleines Framework, Smarty ein großes.

Übrigens: Im Template PHP nicht zu verwenden, geht nicht. Aber in WB ist das ganze sehr komplex.
Denn:
- Wir haben die view.php, wo Template Geschichten definiert werden. In manchen Modulen.
- Wir haben .htt , wo Template Geschichten definiert werden. In manchen Modulen.
- Wir haben .html, wo Template Geschichten definiert werden. In manchen Modulen.
- Wir haben die Datenbank, wo Template Geschichten definiert werden. In manchen Modulen.
- Wir haben .js, wo Template Geschichten definiert werden. In manchen Modulen.

Jetzt meine Frage: Ist das einfach? Ist das Designerfreundlich?

Kleines Beispiel:

Ich war auf der Suche nach einer Bildergalerie, die meinen Wünschen entsprochen hat für hier http://www.websitebaker2.org/de/home/ueber/screenshots.php. Letztendlich habe ich eine gefunden, die hat aber 100 HTML Fehler ausgeworfen. Also ran ans Template - aha, also rein in die view.php.
Dann sucht man sich alles zusammen, wo man denken könnte wo was irgendwie steht, und schon hat man Stunden später sich toll eingearbeitet.

Wäre es dann denn nicht einfacher folgendes Schema eines bekannten, hier aber nicht weiter genannten PHP5 Framework, das zeitgleich ein CMS ist zu verwenden:
- Er definiert in einer seiner .php im Modul die Variablen, die er braucht (z.B. show_next_topic).
- Er nimmt eine view.topics.html und schreibt dann rein:
[sprachdings.show.topics] <b>[+topic.nav.start+]</b> to <b>[+topic.nav.end+]</b> of <b>[+topic.nav.total+]</b>

Fertig isset!
Ich finde es furchtbar, wenn jeder seinen Weg durchboxt - das ist teilweise solch ein Wust, den keiner mehr überblicken kann, auch und gerade in WB. Wenn jetzt jeder Modulautor seinen Weg findet, wie er am Besten Templates darstellt können wir das Wort "einfach" wegstreichen aus dem WB-Wortgebrauch - dann lieber SmartyXXLExtended mit YAML hintendran, weil das hat wenigstens System.

Gruß Michael

[Stefek]

Hallo Michael,

also das hier:

Wenn jetzt jeder Modulautor seinen Weg findet, wie er am Besten Templates darstellt können wir das Wort "einfach" wegstreichen aus dem WB-Wortgebrauch - dann lieber SmartyXXLExtended mit YAML hintendran, weil das hat wenigstens System.

... hat nicht soviel zu sagen.
Warum?
Weil das nur auf das Backend der Module einfluß hat.
Wenn Ralf z.B. wirklich eine bessere Temlate Engine für seinen Newsletter braucht, dann nur zu.
Für phpLib Template würde er sich die Arbeit nur erschwären und für Dich als Nutzer des Moduls hätte es keinen Vorteil.

Wenn Bianka ihre Lib verwendet um Templates darzustellen, dann nur zu - WB2.8.x bringt nicht besseres mit, auf das man aufbauen könnte.

Wenn Thorn PMF einsetzt - wieso nicht? Das hat nur auf das Template im Backend auswirkungen.
Obwohl das ist ein Ausnahmefall.
Weil man PMF auch für die Template Layout Felder verwenden kann (ich meine die Felder, die man z.B. im Newsmodul findet unter Optionen.) Die ganzen Layoutfelder für die Loops usw. die später im Frontend ausgegeben werden.
Das ist sehr praktisch, weil man hier (mit den normalen Mitteln) keine Blöcke aufbauen kann. Sehr kompliziert.
Mit PMF geht es ganz leicht.

Verwendung von Libs
Aber generell ist mir egal, ob die Modulentwickler ihre eigenen Libs verwenden. (Nicht nur für Templates, sondern allgemein.)
Ich selbst würde nie ein Backend für ein Modul mit der phpLib templaten wollen.
Es verlangsamt den Entwicklungszyklus enorm (und die Performance, wobei das im Backend nicht immer so eine große Rolle spielt, wenn nicht zu viele diverse phpLib Blöcke verwendet werden).

Warum die Modulentwickler es tun ist doch geklärt. 2.8.x bringt nicht besseres mit.
Und es ist doch schon mal gut, dass man überhaupt WB 2.8.x auf eine solche Weise erweitern kann.


CODEWÜRSTE != Prozedurales PHP
Das beweisen doch einige gute Module.
Ich bin mir sicher, dass auch unter OOP viel Unlogik fabriziert werden kann.

Ich selbst als Anfänger in Sachen PHP bevorzuge Module die Prozedural geschrieben wurden, weil da so ziemlich immer "von oben nach unten" durchgegangen wird. Ich kann es besser nachvollziehen.
Und eine Codewurst ist mir im derzeitigen Stadium lieber als die Verwendung eines Objektes, einer Klasse, die ich nicht nachvollziehen kann.

Aber das hat nichts damit zu tun was ich mag. Niemand verlangt, dass die Programmierer sich einschränken, damit PHP Beginner sich in den Code eindenken können. Das ist nicht der Zweck beim Modulbau, sollte es nicht sein.

Prozedural auch in nextGen WB möglich
Da auch schon die Frage positiv beantwortet ist, ob in einer nextGen WB Version auch prozedurales Programmieren möglich sein wrd, bin ich beruhigt. Andernfalls würden zu viele Leute vorm Kopf gestoßen werden.

Für mich sind die Themen alle geklärt.

Es macht auch keinen Sinn, das weiter durchzukauen.

Die Struktur eines Nachfolger WBs wird vieles abdecken, sodass die Coder möglicherweise gar nicht mehr so viele eigene eigene Libs einpflanzen werden und Prozedurales PHP wird auch dann noch möglich sein (samt Codewürsten und Spagetthicode).

Da die prozedural entwickelnden Programmierer auch auf die verschiedenen Objekte werden zugreifen können, wird es die Entwicklung bereichern.
Ich bin mir sicher, dass es mehr Vorteile als Nachteie hat.
Und wer aus irgendwelchen Gründen (Wissensstand, Verbohrtheit, Originalität oder sonst was) auf OOP völlig verzichten will, fein.

I'm done here.
Frohes Schaffen.

Stefek

[Waldschwein]

Du hast meine Beiträge nicht so gelesen wie ich ihn geschrieben habe sondern so wie du ihn verstanden hast, daher reden wir zu 98% aneinander vorbei.

Egal.   Hat eh keinen Sinn hier zu philosophieren, die Entscheidungen treffen eh andere.


Gruß Michael

[Stefek]

Man konnte auch kaum was verstehen.

Du warst auch nicht nur gement.
Ich wollte einfach einen Schlußstrich für mich ziehen.
Die Debatte läuft sonst ins Unendliche weiter.

Die Frage war ja OOP / Libs generell, macht das Sinn?

Ja, tut es.
Und in meinem Beitrag habe ich einfach nur "laut zusammengereimt".

I'm fine here.
CU,
Stefek

[wollinche]

Ich verfolge diese Diskussion schon länger. Mit offenen Mund und erstaunten, weitaufgerissenen Augen.
Ich habe keine Ahnung von OOP, ich kann (und will auch nicht) ein raffiniertes Modul schreiben.
Ich kann in einem Modul verstehen was gerade passiert, und ich kann ein Modul nach meinen Vorstellungen ändern.

Ursprünglich bin ich mit einem anderen CMS verbandelt, das ich jederzeit bei umfangreicheren Seiten und bestimmten Funktionen WB vorziehe.
Dieses CMS hat eigene APIs, integriertes pear-Framework, und, und, ...
Mit der Folge das Module nun zwar reines php sind, aber mit Funktionen versehen sind die man als nicht-php-core-beteiligter kaum bis gar nicht nachvollziehen kann weil entweder nur minimal Dokumentiert oder schlecht oder gar nicht.
Ein Beispiel dazu:
Ein Modul breadcrumb besteht aus ca. 8 Zeilen Code.
Änderungen an der Ausgabe des Modules sind so gut wie nicht möglich weil fest im Core eingebaut durch OOP, ...
Folge: Es wurden vom Forum eigene Module programmiert, die nun jeder verstehen kann und auch ändern kann.

Zu WB bin ich auf der Suche nach einem kleinen, einfachen und für Hans Normalo schnell zu verstehenden und bedienbarem CMS gekommen.
Für eine Webseite wollte ich die Darstellung wie sie in guten Tageszeitungen üblich ist nachbauen.
Überschrift (fest in H1), kurze Zusammenfassung des Inhaltes (unformatiert), der Artikel (Inhalt, ggf. formatiert), jeweils als eingenständiges Modul.
Fündig geworden bin ich beim Modul headline, da habe ich sehr schnell verstanden.
Da ich nichts für die Zusammenfassung gefunden habe (eigentlich ein FCKEditor ohne jede Möglichkeit etws zu formatieren) war es ein leichtes das Modul headline umzubauen (anstelle Textfeld eine Textarea) und als Zusammenfassung zu verwenden.

Was will ich damit sagen?
Kann ein Nutzer später (bei OPP oder yxz-Framework) schnell die Modulfunktione verstehen?
Oder schnell die Funktionen verändern, umschreiben, erweitern, ...
Wenn nein, wem nutzt dann der ganze Aufwand?
Dem Entwickler weil er seine Zeit sinnvoll eingesetzt hat und zukunftssicher programmierte?
Mir würde es jedenfalls nicht nutzen und ich brauchte dann kein WB mehr weil ich auf das andere CMS wieder ausweichen würde.

Aber eben nur meine Meinung, eines Nutzers mit Hans Normalo-Kentnissen und keinen weiteren Ambitionen.

[Waldschwein]

Hallo!

Irgendwie komme ich mir hier vor, wie bei Mercedes in der Entwicklungsabteilu ng vom neuen C-Klasse Modell, wo die eine der beiden Gruppe sagt "uns gefällt der Audi A4 besser, weil" und die andere sagt "uns gefällt der BMW 3er besser, weil".

Wir reden hier wirklich über Äpfel und Birnen, respektive reden die einen (Ralf, Bianca, ich) von programmieren, andere (chio, Stefek) von coden. Man kann coden ohne programmieren, und programmieren ohne coden. OOP ist Programmierung, so wie MVC auch. Das hat erst einmal nichts mit herumgecode zu tun, das gibt es auch in anderen Bereichen. "class C-Klasse" kann 100PS oder 500PS haben, kann rot oder schwarz sein, Ledersessel oder Stoff, Coupe oder Limousine - trotzdem ist es dieselbe "class". Und eine "class" kann man mit genügend Objekten befüllen - sie sind so vorgegeben wie es Sinn macht, aber man kann neue hinzufügen, ja sogar alte ändern. Also genau das, was teilweise bisher auch geschieht - oder gibt's in WB keine "Presets"?

@wollinchen: Wenn das so ist wie du schilderst, dann muss ich davon ausgehen können, dass die Leute von dem System das du verwendest schlechte oder gar keine Programmierer sind, sondern bloß wild herumcoden. Sorry das so hart zu sagen (und das hat auch nichts mit der Größe von dem System zu tun!) aber wenn Abstraktion & Vererbung nicht in Verbindung mit OOP benutzt wird, ist es kein echtes OOP.
Trotzdem ist es gut, dass du es so offen sagst, weil man evtl. auch die Leute, die meinen mit OOP (respektive WB3) lösen sich viele Probleme von alleine gezeigt bekommen, dass dem nicht so ist. Gute OOP CMS gibt es kaum welche. Viele schreiben mal schnell ein Framework frei nach dem Motto "sieht doch gleich besser aus", klatschen ein paar Sachen zusammen, machen großes Marketing & gewinnen tolle Preise, aber letztendlich wird das CMS dadurch auch nicht besser.

Aber bitte, bevor hier munter weiter diskutiert wird:
Legt alle eure Scheuklappen ab, vor allem auch die Geschichten á la "mir hat einer gesagt, dass er vor zehn Jahren mal eine OOP Programmiersprache gesehen hat, und der kann programmierern und der hat gesagt das war ja furchtbar grauselig!" sondern beschäftigt euch einmal wirklich mit der Materie, wie es Bianca sagt. Es muss ja einen Grund geben, wieso es heutzutage kaum eine nicht-OOP-Programmiersprache gibt - die sind alle praktisch tot. Man holt sich ja auch schon vieles aus Ruby / Ruby on Rails in PHP.

Gruß Michael

[chio]

Außerdem reden wir hier sowieso um des Kaisers Bart.

Man muss mal auseinanderhalten:

Coder != Anwender
Wenn ein Modul Mist ausgibt, dann ist das Sache des Coders, das in Ordnung zu bringen. Das läuft nicht unter "wenig benutzerfreundlich", weil Fehler eben Fehler sind.
Je "zerfledderter" etwas ist, umso leichter schleichen sich Fehler ein; klar: Wenn man Funktionen (Klassen, Objekte) nutzt, muss man immer im Auge behalten, was rein und raus kommt. Das ist nicht immer ganz leicht, überhaupt wenn das um 5 Ecken geht.

Wenn jeder seine eigenen Libs verwendet, ist es zwangläufig so, dass nur ER sie kennt und deswegen nur ER darauf aufbauende Module pflegen kann.
Deswegen dürfen solche Module/Codeteile niemals in den Core gelangen.

Ich hätte nebenbei überhaupt nichts dagegen, wenn es im Core einige sinnvolle Erweiterungen gibt, etwa wenn das Handling von Bildern vereinfacht wird (Uploader, verkleinern usw), wenn klare und durchdachte Funktionen greifbar sind, die auch irgendwie _dokumentiert_ sind.

[Waldschwein]

Wenn jeder seine eigenen Libs verwendet, ist es zwangläufig so, dass nur ER sie kennt und deswegen nur ER darauf aufbauende Module pflegen kann.

Deswegen bin ich dagegen, dass jeder seine Lib baut, egal ob OOP oder nicht. Aber mir solls egal sein - die Downloadzahlen sprechen ihre eigenen Worte.  Wenn der Modulautor damit glücklich wird - und das ganze vielleicht sogar als "Spielwiese" für das "große, ganze ansieht" kann es ja Sinn machen.

Ich hätte nebenbei überhaupt nichts dagegen, wenn es im Core einige sinnvolle Erweiterungen gibt, etwa wenn das Handling von Bildern vereinfacht wird (Uploader, verkleinern usw), wenn klare und durchdachte Funktionen greifbar sind, die auch irgendwie _dokumentiert_ sind.

-> http://static.scribd.com/docs/908bil5xonqxe.pdf

Gruß Michael

[wollinche]

@wollinchen: Wenn das so ist wie du schilderst, dann muss ich davon ausgehen können, dass die Leute von dem System das du verwendest schlechte oder gar keine Programmierer sind, sondern bloß wild herumcoden.

Naja, wenn ich mir ansehe welche Seiten, mit welchem Umfang, bei welchen Firmen mit dem anderen CMS gemacht sind ...
Ich denke da träumt WebsiteBaker nur von.
Deswegen werte ich diese Außerung als die eines Programmierers der sich auf den Schlips getreten fühlt.

Aber ich sagte ja schon, ich sehe WB in einer anderen Liga, und das ist ja auch gut und richtig.
Nur muß jeder Programmierer sich fragen (lassen) ob das fertige Produkt die Erwartungen erfüllt die die Anwender an das Produkt stellen.
Wenn WB sich mit z.B. dem hier messen will:
https://www.coremedia.com/de
kommen andere Anwender und Kritierien zum Zug als die der jetzigen Nutzer/Anwender.

Und nun Ende für mich hier. Ich habe gesagt was ich sagen wollte, mehr kann ich zum Thema nicht beitragen.

[Luisehahne]

Wer sagt denn, dass sich WebsiteBaker mit irgendwas messen will oder soll. Warum nicht gleich mit Kanonen auf Spatzen schiessen.

Blöde Diskussion hier. Das Thema sollte geschlossen werden, führt eh zu nichts, da Entscheidungen an anderer Stelle getroffen werden. Ich verrate bestimmt nicht zuviel, aber im Team passiert schon einiges. Und ist auch gut, dass es nicht öffentlich gemacht wird. Man sieht ja mal wieder hier das Ergebnis sinnloser Diskussionen.

Dietmar