Beiträge von Netzwerg

Zitat von RainerSF

Nun Du kennst die Schwierigkeiten die sich ergeben wenn man aktuell WBB3.1 /Filebase / WCF Portal zu einer Community zusammen packen will? Ich glaube mir ist das ganz gut gelungen, trotzdem stören mich 1.001 Kleinigkeit.

Ich kenne die Schwierigkeiten, die sich aus dem Multi-Domain betrieb ergeben (soll angeblich mit WCF 2.0 gefixt sein), aber wer wirklich eine Community "aus einem Guss" will sollte eh keinen Multi-Domain-Betrieb haben (irgendwie versteh ich den Sinn nicht, alles "aus einem Guss" haben zu wollen aber gleichzeitig separate Domains), und ich kenne die Schwierigkeiten, wenn man Daten aus einer EA in einer anderen anzeigen will, z.B. wenn man ein gemeinsames Portal schaffen will (hier ist jetzt nicht ein Portal im Sinne des WBB3 Portals von wbbaddons gemeint), in dem gleichzeitig neue Forenbeiträge und neue Filebase-Einträge sind. Das geht nämlich so einfach nicht. Dem sollten die die ApplicationGroups aus dem WCF 2.0 abhilfe schaffen. Einziges Manko. man wird damit nur unterschiedliche EAs verbinden können, also WBB mit Filebase und ggf. mit CMS. aber nicht 2 WBBs miteinander. Insgesamt sind Communities mit mehreren Foren aber eher eine Seltenheit.
Dann gibts da noch so einige Quirks z.B. mit der Moderation (fest ins WBB eingebaut und nicht erweiterbar für andere EAs), mit dem PM System (schwierig referenzierbar ohne eine Abhängigkeit auf ein kommerzielles paket herzustellen) und nen paar kleineren anderen Sachen. Die beiden oben genannten Probleme (Moderation / PNs) fallen im WCF 2.0 aber weg

Zitat

Also gescheiten Blog und gescheiten Kalender hätte sicher nicht nur ich Bedarf. Solltest Du an so Projekt ran gehen, reiche ich dir gern fetten Wunschzettel rüber.

Kalender kann ich dir zu 95% eine Absage erteilen, ich habe da keinen Bedarf (mehr) und der Aufwand steht für mich da in keinem Verhältnis zum Nutzen. Was einen Blog angeht, so werde ich, wenn WoltLab da wieder so einen Profilblog zusammenschustert mit 95%iger Sicherheit meine eigene EA für schreiben - da habe ich selber nämlich Bedarf dran.

Was deinen Wunschzettel angeht => PN. Mich würde durchaus mal interessieren, was andere so als notwendige / brauchbare Funktionen für einen Blog erachten.

Zitat von RainerSF

dass die Suche nach Alternativen zu den Network´s langfristig notwendig ist um ein Überleben eigener Communitys zu gewährleisteten. Da ich dieser festen Überzeugung bin interessiert mich vor allem wie flexibel WCF2 ist. Forum wird immer mehr nur eines von vielen Bausteinchen.

WCF 2.0 bietet dir für eigene EAs auf jeden Fall mehr Möglichkeiten als WCF 1.x. Außerdem wird es durch die ApplicationGroups wesentlich einfacher, verschiedene Endanwendungen nahtlos ineinander zu integrieren. Wobei ich mir jetzt die genauen Details der ApplicationGroups noch nicht angesehen habe, ich glaube da war als ich mir das zuletzt angesehen habe auch noch nicht alles von fertig.

Zitat von RainerSF

Beim WBB4 interessiert mich im Grunde nur welchen Einfluss es im Community Sinn auf andere EA´s hat! Ich könnte jetzt 1.000 Kleinigkeiten aufzählen, die beim WBB3 sehr störend sind. Muss ich aber glaube ich nicht.

Hm, wie genau meinst du das jetzt?

Zitat von RainerSF

Netzwerg Blog und Galerien sind ziemlich gelungen, benötigen aber erhebliche Nachbesserungen. Der Kalender ist grausam, so grausam das ich mich nach einer Alternative sehne.

da stimme ich dir dicherlich zu. Blog und Galerie sind definitiv gut gedacht, aber für mich auch unbrauchbar. Was den blog angeht so habe ich mir auch schon überlegt da mit WCF 2.0 eine eigene EA für zu schreiben, nen richtigen Standalone globalen Blog. Über den kalender brauchen wir denke ich nicht reden, der ist von brauchbarkeit recht weit entfernt. Alleine wenn ich sehe, dass man sich für wiederkehrende termine nicht an jedem Tag einzeln an / abmelden kann wird mir ganz anders. Und das letzte funktionsupdate für den kalender ist auch lange her, der ist ja nur auf WCf 1.1 / WBB 3.1 geported worden, wirklich etwas dran getan hat sich nicht. irgendwie wird der von Wl leider ziemlich stiefmütterlich behandelt. Schade, ich könnte nen wirklich guten Kalender gut gebrauchen. Auch was die erweiterbarkeit angeht istder aktuelle Kalender - sagens wir vorsichtig - unvorteilhaft.

Zitat von RainerSF

Was rollt denn an Veränderungen beim Design auf uns zu? Wie schaut es mit anderen Endanwendungen aus? Wird es schwerer oder einfacher?

Das Design ist noch nicht fertig. ich denke mal die meisten Screenshots wirst du kennen, d.h. du weißt ja, wohin sich das Standardinterface bewegt. wie ich oben schon geschrieben hab setzten die Stylesheets nun auf LESS, was es zumindest einfacher machen sollte umfangreiche zusätzliche CSS deklarationen anzubieten. Allerdings wurde mit den arbeiten am Stileditor noch nicht begonnen (oder er wird wieder ein komerzielles Paket, was auch heißen würde, das wir bis zur Beta warten müssten, bis wir uns den ansehen könnten). Insofern ist es da schwer zu sagen, was sich da so alles ergeben wird.
Was eigene Endanwendungen angeht, so wird es sicherlich einfacher, dort Stile und templates für zu entwickeln. IIm WCF 1.x / WBB 3.x sind noch viele templates vom WBB3 mitgeliefert worden, und man hatte somit mit eigenen EAs teilweise probleme, da man ja nicht einfach Templates aus dem WBB3 kopieren konnte - wie z.B. das header- oder headInclude - Template. Das wird besser, weil im WCF 2.0 diese templates alle direkt ins WCF eingebunden sind. Auch bietet WCF 2.0 imho besser wiederverwendbare Elemente - sprich, es wird einfacher EAs mit konsistentem Aufbau zu erstellen, wodurch natürlich viel weniger Anpassungen an Stilen für andere EAs notwendig werden. Mit ein wenig Glük reden wir bald nicht mehr von WBB stilen, sondern WCF stilen, und diese funktionieren ohne große Probleme dann in allen EAs. Aber wie gesagt, in dem bereich ist noch lange nicht alles fertig und das ist ein wenig über ungelegte Eier spekulieren - hier sollte man für definitive Aussagen noch warten, ich denke aber, es geht zumidest in eine Richtung, die einen positiv stimmen kann.

Zitat von GneX

Objektive Kritikpunkte sind, darauf bist du leider wieder nicht eingegangen, die Wartezeit bzw. Umsetzbarkeit und der Fall mit kostenpflichtigen Paketen. Wir müssen, denke ich, nicht diskutieren, dass es mitunter sehr lange dauern kann, bis WoltLab auch nur kleinere Dinge eingebaut bzw. ein Update veröffentlicht hat. Das behindert extrem in der Entwicklung und Flexibilität.

Es geht hier ausschließlich um die Templatepatches, was dieses einbauen & umsetzen angeht, und dtdesign hat selber mehrfach erwähnt dass man das sehr großzügig handeln will. Er schrieb selber, dass der Anzahl an Template-Events keine Grenzen gesetzt sind, da diese nur einmalig beim kompilieren der Templates ausgeführt werden. Ich denke hier muss man WoltLab einfach die Zeit geben zu beweisen, dass das mit dem anfordern neuer Template-Events, wenn man sie denn wirklich braucht, wirklich gut geht.

Zitat

Es ist für neue Entwickler deutlich schwieriger geworden, einen Einstieg zu finden; das behindert objektiv neue Entwickler (oder auch Administratoren, die etwas selbst entwickeln möchten). Man hätte den grundsätzlichen Aufbau der technischen Struktur eigentlich so lassen können; es ist mitterweile doch recht verwirrend geworden.

Wer wirklich Entwickler ist, der kommt mit der leicht gestiegenen Einarbeitungsaufwand eigentlich klar, da er hinterher damit belohnt wird, weniger Zeit zu benötigen. Wer also viel entwickelt, der sollte die Änderungen eigentlich begrüßen, weil er auf lange Sicht davon stark profitiert.

Wer "in die Röhre schaut" sind die normalen Administratoren, die ab und an mal nen Plugin zusammenbasteln. das wird sicherlich schwieriger. Aber ist nicht wirklich ein Argument gegen WCF 2.0. Es war sicherlich vom Lernaufwand wesentlich einfacher WBB2 Hacks zu schreiben, die Umstellung auf WCF 1.0 / OOP war da auch für viele eine unüberwindbare Hürde. Und dennoch wollen wir denke ich alle nicht zum WBB2-like hacken zurück, weil wir alle wissen, dass ein Paket fürs WBB3 zu schreiben zwar mehr Lernaufwand ist und für kleine Pakete auch aufwändiger ist, als mal eben nen Hack zusammenzuschustern, aber für größere Pakete ist der Aufwand mit WCF 1.x / WBB 3.x dann doch erheblich gesunken.
Es ist tendentiell eben so, dass ausgefeiltere Techniken meist auch erst schwerer zu verstehen sind. BASIC ist sicherlich leichter zu lernen als Java oder PHP, dennoch würde kein vernünftiger Mensch heute mehr mit BASIC (nicht VB, ich meinte richtiges, echtes BASIC) programmieren.

Der grundsätzliche Aufbau ist an sich sogar gleich geblieben. Es sind an einigen Stellen einige konzeptionelle Schwächen behoben worden, die man besser so auch nicht länger hätte mitschleppen sollen und die eine größere Änderung erforderten, und es sind viele neue, wesentlich flexiblere APIs geschaffen worden. das Object / object type System zum Beispiel ist zwar recht komplex, bietet auf der anderen Seite aber viele flexible Möglichkeiten, die so im WCF 1.x gar nicht möglich sind.

Zitat von GneX

Das WBB ist ein Grundsystem,

Wenn du es so siehst, werden wir beide nie auf den selben Nenner in der Diskussion kommen. Ich sehe das schlichtweg anders. Das Grundsystem ist das WCF. WBB ist eine Endanwendung. WBB ist sehr gut erweiterbar, sogar vmtl. besser als WBB3, weil es auf flexibleren Schnittstellen aufbaut. Es ist aber, eben weil es bereits auf dem WCf aufbaut, umfangreicher, und nicht einfach minimierbar. Das ist auch nicht das zeil von WBB4, ein minimales Grundsystem hat man im WCF 2.0.

Und die Erfahrung zeigt, dass der normale User lieber alles "out-of-the-box" hat, anstelle es sich zusammenfrickeln zu müssen. Für den Support ist es auch einfacher, wenn eine gewisse gemeinsame Basis bei allen WBB4s vorhanden ist, anstelle wenn jedes WBB4 andere Vorraussetzungen hat.

Zitat

Wo liegt das Problem EIN Zusatzpaket anzubieten

Jap, und das machen wir bei jedem Paket und schwupps ham wir 10 Zusatzpakete oder mehr und die Paketzahl mal eben verdoppelt.

Zitat

Ich schrieb, dass ich WEDER die Zeit NOCH die Lust habe.

Ja, und das ist objektiv gesehen ein Kritikgrund am WCF 2.0 weil ... ?

Zitat

Ich bestreite ja gar nicht, dass es technisch besser ist, aber es ist deutlich komplexer geworden, überhaupt einen Einstieg zu finden bzw. zu wissen, wie und wo ich etwas nutze(n) (muss).

Siehe oben, das ist objektiv ein Kritikgrund, weil .... ?
Natürlich ist das System komplexer geworden, und die Lernkurve hat sich verändert, das habe ich oben ja bereits geschrieben. Das lässt sich aber, wenn sich ein System weiterentwickelt, schlichtweg nicht vermeiden, und ist auch nicht wirklich etwas, das man als Argument gegen WCF 2.0 bringen könnte, zumindest nicht in objektiver Hinsicht.

Es mag ja sein, dass für dich diese Gründe gegen WCF 2.0 sprechen. Das sind aber Gründe die rein subjektiv dich selber betreffen und sich schlichtweg nicht für eine objektive Diskussion über Vor- und Nachteile von WCF 2.0 eignen, denn die persönliche Situation eines einzelnen spielt für die Qualität des Frameworks schlicht keine Rolle.

Das wär ja so wie wenn ich in einer Diskussion über Joghurt hingehe und sage Mango-Joghurt ist schlecht weil ich ihn nicht mag und nicht nutzen werde. Das mag zwar wahr sein, beantwortet objektiv aber nicht die Frage nach der Qualität bzw. Genießbarkeit des Mango-Joghurts.

Zitat von GneX

Ich beziehe mich eigentlich gar nicht auf einen speziellen Teil des Systems (WCF, WBB, ...) sondern sage lediglich, dass ich ein Grundsystem als Grundsystem verstehe, welches möglichst minimal aufgebaut sein sollte.

Sorry, aber das WBB ist einfach kein Grundsystem sondern eine Endanwendung. Das Grundsystem ist das WoltLab Community Framework. Du versucht hier absichtlich Dinge durcheinanderzuschmeißen die so rein gar nichts miteinander zu tun haben. Nochmal: WBB ist keine RCP. Wenn überhaupt, so könnte man das WCF eher mit einer RCP vergleichen.

Zitat

Sicherlich ist es aber nur wenig Speicher ... für mich zählt aber, dass dort etwas vorhanden ist, was ich eh nicht brauche. Das geht mir zum Beispiel jetzt auch so: Leider wird das Hilfesystem als Abhängigkeit definiert, so dass ich dort nun unnötig Dateien und Tabellen habe, die ich nie benötigen werden, weil ich ein eigenes Hilfesystem nutze.

Und was hindert dich daran, dein eigenes Hilfe-System im WCF 2.0 zu verwenden? In deinen eigenen Endanwendungen kannst du dein eigenes Hilfesystem verwenden, das geht ohne Probleme. Und wenn du in einem von dir eingesetzten WBB das built-in Hilfesystem nicht willst, so schaltest du es ab, und aktivierst dafür dein eigenes.
Das bedeutet natürlich, dass du dein Hilfesystem so gestalten solltest, dass es nicht mit dem von WoltLab kollidiert. Das solltest du aber eh tun. Denn genau in dem Falle, wenn jemand anders auch eine EA schreibt und ein Hilfesystem braucht, wird er vmtl. auch das von WL zurückgreifen. D.h. deine eigenen Anwendungen sollten immer kollisionsfrei mit allen anderen Paketen laufen (alles andere wäre auch einfach nur schlampig bzw schlechter Stil).
Außerdem ist das Hilfesystem ein Beispiel par excellence dafür, wieso es Sinn macht, weitere Pakete direkt ins WBB zu integrieren. WoltLab möchte im WBB eine Hilfe anbieten. Also setzen sie eine Abhängigkeit auf das Hilfssystem und liefern per PIP die entsprechenden Hilfethemen mit. Genau dafür ist das Paketsystem mit seinen Abhängigkeiten gedacht. Jetzt hinzugehen, ein optionales WBB-Hilfspaket zu erstellen, dass dann wiederum das WCF Hilfspaket benötigt, ist schlichtweg grober Unfug und wirkt genau dem Ziel, das man sich gesetzt hat, nämlich den Paketdschungel zu entwirren, entgegen.

Das WCF als Grundsystem ist genau das, was du dir hier eigentlich die ganze Zeit wünscht - ein flexibles, sehr modulares System welches nur einige Grundfunktionen bereitstellt, aber durch weitere Pakete beliebig erweiterbar ist. WBB hingegegen ist bereits eine konkrete Implementation auf Basis dieses Grundsystems. Selbstverständlich liefert also WBB bereits einiges an Funktionen mit und ist von einigen Paketen abhängig.

Ich kann deine Aufregung darum ehrlich gesagt nicht wirklich nachvollziehen.

Zitat

ür den professionellen Einsatz eignet sich das WBB3 weiterhin wunderbar: Kein Schnick-Schnack, solide Basis und ein Grundsystem, welches nicht mit unnötigen Dinge vollgestopft ist.

Wie gesagt, man kann alles, was man nicht braucht abschalten => Problem gelöst.

Zitat

Ich habe weder die Zeit noch die Lust mich näher mit Git zu beschäftigen, um Änderungen vorzuschlagen.

Man stellt von einem internen SVN auf öffentliche Git-Repos um, präsentiert dir quasi alles auf dem Silbertablett, und du kanzeltst das einfach ab mit "hab ich keine Lust zu". In dem Falle kann man nur sagen: Dann lass es bleiben.
Viel mehr Möglichkeiten, andere Entwickler direkt in die Entwicklung von WCF einzubinden gibt es kaum. Du solltest dir nur mal überlegen, wie das rüberkommt: Auf der einen Seite bist du die ganze Zeit nur am meckern, auf der anderen Seite schlägst du solche Möglichkeiten völlig aus. Ja was zur Hölle soll man denn noch machen, um es dir recht zu machen? Sorry, da kann man nur sagen: Selber schuld.

Zitat

Ich beziehe mich auf den technischen Aufbau.

Der technische Aufbau von WCF 2.0 ist wesentlich besser als der von WCF 1.1. Die API hat sich stark verbessert und macht vieles einfacher als es derzeit im WCF 1.1 noch ist. Ich muss allerdings sagen, ist schon eine respektable Leistung, sich einen Eindruck vom technischen Aufbau des WCF 2.0 gemacht zu haben, ohne sich mit Git auszukennen (schließlich ist das WCF 2.0 ja ein Git Repo).

Zitat

Davon ab hätte ich dann viele Sachen ungenutzt auf dem Server liegen, weil ich eh meine eigenen Dinge nutzen würde, da mir der Aufbau von WoltLab nicht gefällt und auch nicht in das Konzept passt.

Wenn du ein grundlegendes Problem mit dem technischen Aufbau des WCF hast solltest du dir eventuell überlegen, ein anderes Framework zu verwenden, welches deinen Vorstellungen näher kommt. WCF ist nicht das einzige OOP-Framework für PHP.

Woltlab hat hier eine bestimmte herangehensweise gewählt (die sich im WCF 2.0 nicht wesentlich von der im WCF 1.1 unterscheidet, man hat im WCF 2.0 allerdings die Möglichkeit genutzt einige der konzeptionellen Schwächen von WCF 1.1 zu korrigieren). Wenn dir diese Herangehensweise so viele Probleme bereitet, wieso nicht gleich auf etwas anders umsteigen?

Das klingt jetzt vielleicht etwas hart, entspringt aber durchaus einer gewissen Erfahrung. Den meisten sollte ja bekannt sein, dass ich wesentlich mehr in Java programmiere, als in PHP. Dort habe ich es mir z.B. auch zur Angewohnheit gemacht, verschiedene Frameworks zu evaluieren, und je nach Situation das Framework einzusetzen, dass sich besser eignet oder einfach meinen Vorstellungen besser entspricht. So habe ich früher z.B. Swing als ziemlich unbrauchbar empfunden und viel mit SWT gemacht. Inzwischen ist aber nicht mehr Java 1.4 aktuell, sondern Java 7, und Swing ist ein sehr gutes Framework geworden. Inzwischen nutze ich also wieder Swing, obwohl ich mich eigentlich in SWT sogar besser auskenne. Die Frage wäre also: Wieso evaluierst du nicht einmal andere Frameworks, wie z.B. Flow3 oder cakePHP?

Zitat

Die Erweiterungen können dem Installationspaket doch direkt beigelegt werden.

Ja, und Erfahrungsgemäß installieren die User da entweder alles oder gar nichts und suchen somit hinterher doch wieder Pakete.

Zitat

Schade, dass du mal wieder nicht diskutieren kannst. Kennt man ja nicht anders von dir. Ich habe schonmal gesagt, dass ich mich ausschließlich an den bisher vorgestellten Sachen orientiere. das hat auch nichts mit "Bashen" zu tun, sondern damit, dass ich anderer Meinung bin. Aber das kenne ich mitterweile von den WoltLab-Fanboys nicht mehr anders und das hast du gerade wieder einmal bewiesen.

Wollen wir jetzt wirklich auf DAS Niveau absteigen? Bist du schon so verbittert und verbissen in dein Gemecker, dass du nun prinzipiell gegen alle anderen querschießt? Ne is schon Gut, illy ist nen Fanboy (und ich dann ja vmtl auch), und du bist nen Hater, können wir jetzt alle in unsere Ecke gehen und uns schämen? *kopfschüttel*

Zitat von Gabbid

ist es deiner Meinung nach trotzdem realistisch und mit etwas Lernwillen machbar, dass man auch das neue WBB selbstständig administrieren kann

Ich sprach davon eigene Plugins gegen die neue API zu implementieren, nicht vom administrieren eines Forums. An der Administration wird sich nicht wirklich viel ändern. Die Oberfläche sieht ein wenig anders aus, manche Dinge sind ein wenig anders angeordnet, aber das wars auch schon.

Zitat

Auf der anderen Seite muss ich einen vermutlich provokanten Punkt anführen, der mich beschäftigt und nicht komplett zu ignorieren ist. Wenn WBB komplexer ist, sich auch die preisliche Situation verändern würde - siehst du die Chance (ich spreche absichtlich von einer "Chance" und nicht darüber, dass man die vielzitierte "Taschengeld-Software" quasi zum Schleuderpreis verhökert), dass sich auch Betreiber vorab genauer informieren und einlernen werden, eben weil es anspruchsvoller ist, oder schreckt es ab?

Man sollte hier verschiedene Dinge nicht vermischen:
a.) Die Bedienung für Benutzer (& Moderatoren)
b.) Die Administration für den Betreiber
und c.) Die Implementation eigener Plugins für Entwickler.

Wieso ich c.) überhaupt angesprochen habe ist die Tatsache, dass viele Betreiber eben neben der Administration gerne dazu neigen, auch eigene Plugins entwickeln zu wollen (was auch sehr gut ist). Und genau da liegt der Hase im Pfeffer: an a.) und b.) ändert sich nicht viel, einiges geht sogar noch etwas glatter von der Hand (der WYSIWYG Editor z.B. wird besser, die Inline-Bearbeitung auch), aber an c.) ändert sich einiges. Es wir für einen "normalen" Admin, der nicht viel Ahnung vom WCF 2 hat mich Sicherheit etwas schwerer, die Zusammenhänge alle richtig zu verstehen, bis er so ein Plugin vernünftig fertig hat.

Zitat

und dann die "Business"-Variante mit Shop usw.?

Business != Shop.

Ein Forum für eine Firma (teils sogar nur im Intranet verfügbar) braucht sicherlich keinen Shop.

Zitat von GneX

Ein Beispiel: Das Gästebuch wird nun zwingend angeboten, gab es bisher immer zusätzlich. Anstatt nun alles in das Grundsystem zu stopfen, hätte man auch das Pluginsystem überarbeiten und intuitiver gestalten können.

Nur, dass das Gästebuch erst später entwickelt wurde. Die Pakete, die es bei Erscheinen von WBB3 bereits gab wurden damals direkt eingebunden, nur die weiteren Pakete kamen später.

Außerdem werden Blog, Galerie und Kalender weiterhin separat bleiben.

Zitat

Welchen Sinn macht ein Moderationslog, wenn es sich ausschließlich auf Themen bezieht? Dann habe immer noch keine Kontrolle über andere Dinge.

Aber ca. 95% der Anwender haben genau das abgedeckt, was sie bei weitem am meisten nutzen - das Forum.

Zitat

Anstatt nun alles in das Grundsystem zu stopfen, hätte man auch das Pluginsystem überarbeiten und intuitiver gestalten können. Davon ab sprach ich auch nicht davon, dass es das Pluginsystem nicht mehr gibt, sondern davon, dass ich eine gesunde Abwägung von Grund- und Zusatzfunktionen vermisse.

Nur, dass du hier konsequent zwei Dinge verwechselt - das Grundsystem ist das WCF, und nicht das WBB. Und das WCF ist, dank dem entheddern der Abhängigkeiten, so modular wie nie zuvor. Schau dir doch mal an, wovon das Userprofil im WCF 1.1 so alles abhängt, und welche Pakete du tatsächlich alle einbinden musst, um das Userprofil-Paket zu haben. das ist das halbe WCF. da ist man einen sehr großen Schritt nach vorne gegangen, indem man da die Abhängigkeiten wesentlich entzerrt hat. Du kannst jetzt eigene Plugins / EAs mit wesentlich weniger expliziten und impiziten Abhängigkeiten schreiben, als je zuvor.
So wie ich das lese würdest du am liebsten eine Art RCP haben - so ist das WBB aber nicht gedacht, und so war auch das WBB3 nicht. WBB4 wird eine solide Basis sein, und es wird dennoch jede Menge Plugins für die weitere Anpassung geben. Das Einbinden bestimmter Eigenschaften über direkte Abhängigkeiten ist nicht nur technisch gesehen sinnvoll, sondern auch für den benutzer.

Zitat

Die Dateien, Tabellen und co liegen auf dem Server ...

Und fressen dort überhaupt kein Brot. oder willst du mir erzählen, die paar KB Speicherplatz hast du nicht frei?

Zitat

Lässt sich bisher schlecht sagen. Ein Beispiel für etwas völlig unintuitives: Die zusätzliche Trennung in Endanwendungen und Erweiterungen; nun ist fast jedes mal ein zusätzlicher Klick nötig. Hier hätte man es wie bisher handhaben können: Eine Tabelle, die meinetwegen geteilt ist (wie im Forum mir wichtigen und normalen Themen).

ja, die Stelle ist tatsächlich unglücklich gelöst. ich meine, ich kann die Intention dahinter verstehen, man will EAs und Plugins stärker trennen, da dies, schaut man sich die Beiträge im WSF so an, den meisten Benutzern nicht wirklich klar zu sein scheint. Andererseits, so wirklich glücklich gelöst sieht das nicht aus. Allerdings ist das nur eine einzig Stelle in der Software, und zwar eine, die nur Admins zu sehen bekommen, nicht die ganz normalen User. Bisher ist die retsliche Oberfläche doch sehr gut geraten und zu den größten teilen auch übersichtlicher als im WBB3. Um genaueres sagen zu können ist es aber definitiv noch zu früh.

Zitat

Keine TemplatesPatch's mehr

Gott sei dank gibts den Quark nicht mehr. War eh ziemlich unnütz, weil man oft andere Workarounds machen konnte. Template-Listener sind da definitiv eine große verbesserung. Und bevor jetzt wieder das alte Argument mit den Events kommt: Die kann man per Pull-Request vorschlagen und diese werden auch in fehlerbehebungs-Updates eingebaut.
Insgesamt überwiegen die Vorteile von Template-Events die Vorteile von template-Patches bei weiten - nicht zuletzt, weil fehlerhafte template-Patches eine häufige Quelle von Problemen mit Plugins sind.

Zitat

und verkomplizierung des Aufbaus.

Kannst du das ggf. weiter Ausführen? Der Aufbau wovon? Der Oberfläche? Der Datenstruktur? Von welchem "Aufbau" reden wir da gerade? Technisch gesehen? Optisch gesehen?

Zitat

Schwierig zu sagen. Ich sehe den Einsatz für professionelle Foren (solche Foren, hinter denen Kunden stehen > abgesehen von WoltLab) nicht mehr. Ich persönlich werde auch nicht umsteigen (mir wäre dafür auch das Geld zu schade).

das Argument bringst du immer wieder, aber irgendwie seh ich nicht wirklich, wieso das so sein sollte. zum einen: Was ist die alternative, zu der solche Firmen greifen sollen? Andere Forensoftwares haben diese Features zum größten teil genauso, weshalb das kein grund ist, diese dem WBB vorzuziehen. Zum anderen kommt die Abschaltbarkeit hinzu, den meisten Firmen reicht das völlig aus, wenn sie mit ein paar klicks im ACP die Software genau ihren wünschen entsprechend einstellen können. Zum anderen punktet WBB4 mit einem schlanken, modernen, seriösem Look, mit dezenten icons und stromlinienförmiger oberfläche. ich sehe nicht wirklich, wieso man sich als firma da gegen WBB4 und für ein Konkurrenzprodukt entscheiden sollte.

Zitat

1. Wo seht ihr aus Sicht des Entwicklers/Designers konkrete Nachteile, die sich vielleicht schon abzeichnen?

Die Lernkurve verändert sich. Es wird zwar etwas einfacher, Plugins auf grundlage von WCf 2.0 zu entwickeln, was die absoluten Basisfunktionen angeht (eine eigene Page erstellen, eine eigene form ersstellen, eigene DBOs erstellen), aber gleichzeitig wird da auch viel logik versteckt so das für Neueinsteiger die Zusaamenhänge, die man verstehen sollte, wenn man dann etwas komplizierteres versucht, nicht mehr so leicht zu erkennen. Außerdem werden doch einge neue Ansätze benutzt, was z.B. die object types angeht. Dies alles zu verstehen braucht eine Weile und erhöht die Einarbeitungszeit. Dafür wird man aber damit belohnt, dass dann, wenn man sich die Mühe gemacht hat, die Entwicklung neuer plugins / EAs WESENTLICH einfacher und schneller abläuft.

Was designer angeht, o ist es zu früh, dazu etwas zu sagen. Das Stilsystem / der stileditor ist noch nicht vorhanden, da sind bisher keine großen Aussagen zu treffen. da WCF 2.0 jedoch auf LESS setzt würde ich dazu neigen zu behaupten, dass umfangreichere CSS änderungen um WCF 2.0 einfacher werden.

Zitat

WoltLab gibt der "breiten Masse" das, was sie möchte, oder denkt ihr, dass überspitzt gesagt nur die Feature-Freunde auf ihre Kosten kommen werden?

um ehrlich zu sein denke ich, es wird genauso laufen wie beim wechsel von WBB2 zu WBB3. Es wird einige geben, die beim WBB3 bleiben, und diese werden das auch sehr lautstark kundtun. Letzten Endes denke ich aber schon, dass eine deutliche Mehrheit mit dem WBB4 besser fahren wird als mit dem WBB3. WBB4 enthält viele verbesserungen, und viele der neuen features waren durchaus immer wieder von kunden angefragt worden. Insofern sehe ich Woltlab da durchaus etwas auf den markt werfen, was aktuelle Trends gut aufgreift.

Zitat von GneX

Und wozu ist das gut? Mir erschließt sich der Sinn (außer sinnfreie Speicherplatznutzung) nicht ...

Das ist eine Funktion, die im WSF immer wieder nachgefragt wird.
ich kann das auch durchaus verstehen, das schafft transparenz. Im übrigen finde ich die Begründung "Man sollte eh nur Leute ins Team aufnehmen, denen man vertraut", doch arg vorgeschoben bzw. nicht zu Ende gedacht.
nahmen wir mal den ganz einfachen Fall. User X erstellt Thema Y, welches gegen die Regeln verstößt und von Mod A gelöscht wird. Mod A geht danach erstmal schlafen oder fährt in urlaub. oder wird überfahren. Mir egal, auf jedenfall ist er erstmal nicht erreichbar. Nun kommt User X her nd beschwert sich bei Mod/Supermod B über den bösen Mod A der sein thema gelöscht hat. Steht nun in so einem log alles wichtige drin, so kann man den User X bequem darauf hinweisen, wer sein thema wann und wieso gelöscht hat, und hat keinen weiteren Ärger. Selbst wenn Mod A aus welchen gründen auch immer dazu nichts sagen kann.
Außerdem funktioniert dieses System mit "Man sollte nur Leute aufnehmen, denen man vertraut" nicht mehr so einwandfrei, wenn das Board eine bestimmte Größe erreicht hat - schaut auch mal board.ogame.de an, dann wisst ihr, was ich meine. In solchen Fällen sorgt ein solches Log für Transparenz und kann viel ärger vermeiden.

Zitat von GneX

Zudem macht gerade dieser Moderationslog (oder auch die Aktivitäten) nur Sinn, wenn auch Fremderweiterungen sich daran beteiligen.

Für den Moderationslog sehe ich das nicht so, der macht auch Sinn, wenn er nur für posts/Themen gilt. Bei den Aktivitäten gebe ich dir teilweise recht, da wäre es wirklich wünschenswert, wenn Drittentwickler diese auch einbinden. Die meisten Drittentwickler, die Erweiterungen haben, die eine größe erreichen, das sich das lohnt, werden dies aber meist eh tun, da ich ansonsten mir ziemlich gut vorstellen kann, dass sie dauernd wieder User auf der matte stehen haben, die genau das Fordern. Es sollte eigentlich im Sinne jedes Drittentwickler sein, solche Funktionen - wenn sinnvoll - zu unterstützen.

Zitat von GneX

Kurz oder lang ist das WBB4 für mich nichts; es bietet keinerlei Vorteile und wirkt einfach nur noch überladen und verspielt. Für einen professionellen Einsatz (z.B. in größeren Foren von Unternehmen) sehe ich das WBB4 nicht mehr.

Von der Oberfläche her sehe ich das ganu anders. WBB3 wirkt, v.a. durch seine quietschebunten Icons, teils doch sehr verspielt. WBB4 geht da einen wesentlich seriöseren/professionelleren Weg. Was die Zusatzfunktionen angeht, die kann man über die Modulsteuerung abschalten

Zitat von GneX

Warum bleibt man dem bisherigen Konzept der Erweiterbarkeit nicht treu, um so jedem selbst zu ermöglichen, was er in das System einbauen möchte und was nicht? Das verstehe ich (leider) nicht ...

Du redest hier einen "bisherigen Weg" herbei, den es so nie gegeben hat. Auch WBB3 bindet zusätzliche WCF-Pakete zwingend ein, z.B. das Tagging-System. Zum anderen ist die Erweiterbarkeit nirgendwo beschnitten - für deine eigenen Plugins / EAs kannst du immer noch, genauso wie bisher, diese Pakete einbinden oder auch nicht.

Ein grund, wieso z.B. im WBB3 das Tagging-System zwingend eingebunden wird und im WBB4 weitere Pakete ist Performance. Du kannst einfach das, was du nicht benötigst, über die Modulsteuerung abschalten. Du willst keine Aktivitäten? Na dann schalt sie ab. Das funktioniert so herum ohne großen Performance-Verlust.
Bindest du hingegen alle Pakete nur optional ein, so hat erstens der User bei der Installation hinterher eine riesen Latte an Auswahlmöglichkeiten, mit denen die meisten Wohl schlicht erstmal überfordert wären. Zum anderen ist das Einbinden über die große Masse an EventListenern nicht nur mühselig, sondern hat auch einen Ausschlag auf die Performance - den man sich da dann total unnötigerweise abholen würde.

Marcel hat selber schon gesagt, dass man diese Features alle über die Modulsteuerung abschalten kann. Und für deine eigenen Entwicklungen ist es eh egal, was WBB4 so alles direkt einbindet. Insofern kann ich deine bedenken in der Hinsicht nicht wirklich verstehen.

Zitat von GneX

und das Framework nur überladen.

In wie fern überladen Funktionen, die ins WBB eingebaut werden das WCF? Insgesamt wurde das WCF sogar besser modularisiert weil es nicht mehr so viele Pakete mit so vielen Querabhängigkeiten gibt. Die WCF Pakete sind jetzt weitgehend eigenständig und somit besser separiert nutzbar.

Zitat von GneX

Ich persönlich nutze auch keine vorkonfigurierten Betriebssysteme, sondern installiere mir ein schlankes System und dann die Software, die ich benötige.

Du bist aber nicht der normale Anwender. Der normale Anweder möchte, das einfach alles, was er barucht, von vorne herein da ist. Er will sich nicht durch plugins wühlen, lesen, was es gibt,evtl. bei Drittherstellern Support suchen. Das macht Arbeit. Das ist von den meisten nicht gewollt.

Zitat von GneX

Ich bin mir nicht sicher, ob WoltLab alle Funktionen abschaltbar macht. Selbst dann wäre das System durch unnötige Dateien, Tabellen in der Datenbank (...) überladen. Ich kenne Foren und deren Benutzer, die z.B. nicht möchten, dass sie in den Aktivitäten auftauchen.

Du bist dir aber schon darüber im klaren, dass ein paar Tabellen in der Datenbank, die einfach nicht benutzt werden, sowie ein paar Konstanten zur Modulsteuerung, die benutzt werden um Module an/abzuschalten, für die Performance recht egal sind, während eine recht große Anzahl an EventListenern durchaus langsamer ist, als den Code direkt einzubauen?

Das WBB wird sicherlich mit einer vielzahl von Funktionen aufwarten. Wie du damit aber auf die Idee kommst, dass das WCF deswegen überladen wird, ist mit ein wenig schleierhaft. Alles in allem ist es immer noch ein Framework, dessen Funktionen (wie das Like System) man implementieren kann, aber nicht muss.

Naja, das Infinite Portal hat schon eine recht gewöhnungsbedürftige Herangehensweise an die Dinge. Nicht umbedingt schlecht, aber imho auch nicht umbedingt die beste.
Will man einfach mal eben ein paar einfache Seiten erstellen, so muss man beim Infinite Portal schon ein wenig tüfteln, bis man da den richtigen Dreh gefunden hat.