alcaeus hat geschrieben:Naja, egal welcher Aufwand es waere, es ist definitiv etwas dass es noch nicht gibt, und mittlerweile muss man da wirklich was finden was nicht alltaeglich ist
Greetz
alcaeus
naja lightmodded gibt es wirklich fast keine, mir fällt auch auf das einige premodded-"hersteller" meist ihr system gernicht verwenden da es auf die zielgruppe zugeschnitten ist und damit als supportforum schon reichlich ungeeignet
Mit NOCH einem Premodded Board wird sicherlich niemand in helle Begeisterungs-Ergüsse ausbrechen. Davon gibt es jetzt schon zuviele. Daran kann auch das gerinfügige Anpassen oder Erweuterb der einzelnen Mods nichts ändern. Und spätestens wenn Olympus rauskommt wird da kein Hahn mehr nach krähen. Selbst große Premodded-Anbieter wie Plus oder Orian müssen dann damit rechnen dass einige User zur Basis-Version zurückkehren weil ein großteil der ganzen Mods einfach überflüssig wird...
Was das Modding angeht habe ich mir da schon mehrmals Gedanken drüber gemacht. Möglichkeiten gäbe es da. Man könnte in jede Datei eine Art Jump-Points einbauen. An wichtigen Stellen im Quelltext (zB beim Auslesen der Daten aus der DB) setzt man zB einfach entsprechende Jump-Points über die in eine andere Datei gesprungen wird in welcher der eigentliche Mod-Code eingebunden wird. Das ist zwar ein etwas größerer Aufwand für die MOd-Programmierer hätte aber den entscheidenden Vorteil, dass man Mods leicht deaktivieren bzw. Ausbauen kann und vor allem dass man ein Board ohne Probleme per One-Click updaten kann, weil im Ursprungs-Code keine Änderungen enthalten sind...
Uncle Sam hat geschrieben:Was das Modding angeht habe ich mir da schon mehrmals Gedanken drüber gemacht. Möglichkeiten gäbe es da. Man könnte in jede Datei eine Art Jump-Points einbauen. An wichtigen Stellen im Quelltext (zB beim Auslesen der Daten aus der DB) setzt man zB einfach entsprechende Jump-Points über die in eine andere Datei gesprungen wird in welcher der eigentliche Mod-Code eingebunden wird. Das ist zwar ein etwas größerer Aufwand für die MOd-Programmierer hätte aber den entscheidenden Vorteil, dass man Mods leicht deaktivieren bzw. Ausbauen kann und vor allem dass man ein Board ohne Probleme per One-Click updaten kann, weil im Ursprungs-Code keine Änderungen enthalten sind...
klingt schön, aber wenn man es optimieren will, dann fällt das schon wieder aus
Grund: nimm an das eine art nickpage und ein Birthday Mod da sind, bei beiden werden user Felder abgefragt. Je nach Einstellung ist das dann in einer anderen Tabelle kann mit anderen Sachen zusammen abgefragt werden etc ...
Theoretisch muss für fast jede Einstellung eine eigene Datei her
die einzige halbwegs sinnvolle Möglichkeit einfällt ist die templates allgemein zu halten und alle anderen Dateien in includeten Dateien in Unterverzeichnissen zu speichern
Je nach Einstellung werden die Dateien aus einem Verzeichnis genommen
da reicht anfangs ein switch das den Pfad herausfindet...
aber ich glaube das ist ein bisschen übertrieben, oder?
Die Weisheit verfolgte mich sekundenlang...
Aber sie überholte mich und war fortan nicht mehr gesehen !!!
ÄÄhh.. gut ich weiss nicht, ob ich es richtig verstanden habe.. aber wenn ich es richtig verstanden habe.. .dann ist es Quatsch...
Es geht also um Erweiterbarkeit von verschiedenen Bereichen.. nehmen wir uns den User raus.. bis jetzt haben wir eine Usertabelle, die statisch n Felder hat, also auch n Attribute anspricht.
Erzeugen wir jetzt nach OOD ein Objekt User (also wir schreiben eine Klasse) und legen intern fest diese n Attribute an.
Jetzt erstellen wir ein Mod und müssen m Attribute hinzufügen.. auch in die Tabelle müssen neue Felder rein usw usw..
Richtig.. hier ist es schwer eine wirkliche Pflege zu machen, bzw das flexibel zu halten, nach dem Motto, wer will was haben..
Wenn ich aber einfach eine Tabelle User habe, die die default Sachen.. wie Namen, eMail, Pswd etc beinhält reicht das.. würde auch reichen für ein miniest Forum, wo nicht mehr rein soll..
Alle anderen Attribute werden jetzt einfach in der DB in einer Seperaten Atr. Tabelle eingefügt und über eine zweite Tabelle als n:m Verknünpfung angesprochen.. beim OOD wird das als Array/Linked/oder was weiss ich List abgelegt.. somit kann man auch leicht Mods, die so abgelegt werden an bzw aus schalten...
Jetzt ist es auch ein einfachstes die Sachen aus dem Objekt zu bekommen und in ein Layout/Template/schlagmichtot zu packen.. auch hier wäre die Möglichkeit über ein Array bzw über das Objekt ansich..
Ich sehe da nicht so die Schwierigkeit.. .aber egal.. Schwamm drüber.. ich kann hier nur sagen, was ich auch bei dem anderen 'Projekt' gesagt habe.. es ist das n. Mal das sowas versucht wird.. ich sehe einfach weder die Notwendigkeit noch die Vorteile an sowas.. vor allem weiss ich nicht, wo es hingehen soll.. kann man zu Olympus 'zurück' wechseln.. wird es wirklich ein eigenständiges Projekt, welches auch in n Jahren noch allein dastehen kann.. was soll das ganze... aber egal.. ich wiederhole mich..
Das Tolle daran, die einzige zwischen richtig und falsch unterscheidende Art zu sein, ist, dass wir uns immer genau die Regeln ausdenken können, die uns gerade in den Kram passen.
Douglas Adams - Die letzten ihrer Art
@Amlor: So in der Art hab ich mir das vorgestellt. Einziger Nachteil ist dass die Programmierung der Mods aufwändiger wird. Ich habe das hier lokal provisorisch mal getestet. Hier läuft ein Olympus-Clone, mit ca 20 großen und kleinen Mods und es funktioniert recht gut. Updaten kann ich indem ich einfach alle Dateien überschreibe und einen zusätzlichen Befehl in der page_header()-Funktion einfüge.
@Shwepsi:
erstens kann man auch innerhalb von SQL-Queries solche Jump-Points setzen, und zweites gibt es wie Amlor beschrieben hat, die Möglichkeit einer eigenen Tabelle, was bei einem Nickpage-Mod so oder weitaus effektiver wäre (stichwort Normalisierung).
@Uncle Sam:
Jump points müssten aber verdammt viele gesetzt werden
und ok, der nickpage mod war vielleicht nicht das beste Beispiel....
aber ich nehme an du kennst genug Mods die nur ein oder 2 Felder hier und da ergänzen ...
dafür eine eigene SQL Abfrage wäre unsinnig - hat man den Mod nicht eingebaut kann es zu Fehlern führen da die Felder nicht existieren usw...
sicher geht es, aber es wäre eine Schweine Arbeit - und vermutlich wäre das Ressourcen schonenste echt einfach je nach Anordnung der Mods eine eigene Version anzubieten ... aber naja ... so der Experte bin ich nicht
(lieber mal als anfänger bezeichnet)
nur ich mag es halt wenn die Mods mit dem Forum verschmelzen und es aussieht als wäre es von anfang an drin gewesen ... keine zusätlichen SQL Abfragen, oder am besten doppelte weil ja jetzt ein Feld noch fehlt was in der anderen ...
was auch gerne vergessen wird sind die Tabellen beim Backup zu integrieren oder es werden keine Constanten genutzt... ach... ich glaube das wisst ihr noch viel besser als ich
Die Weisheit verfolgte mich sekundenlang...
Aber sie überholte mich und war fortan nicht mehr gesehen !!!
Hmm das mit dem Aufwendiger ist jetzt wieder sujektive Empfindung.. alles ist Quick'n'Dirty schneller bzw mit weniger Aufwand geschrieben.. aber erweitert, gepflegt oder was weiss ich kann es dann kaum... von daher sollte man es sich vom Anfang an angewöhnen.. und dann fällt es imho auch garnicht so sehr auf, das es 'mehr Aufwand' ist.. aber egal.. Schwamm drüber..
Das Problem was ich nur sehe.. wie will dann irgendein Mod/Projekt/SchlagMichTot dann noch garantieren, das ein Konverter gebaut werden kann, so dass man zu Olympus zurück kommen kann... bei Olympus ist die DB-Struktur noch nicht mal ganz sicher und hier sprechen wir von Konzepten, die teilweise gänzlich einen anderen Weg gehen. Gut.. ok.. Nachrichten und User übernehmen.. das halte ich für möglich.. aber der ganze Rest.. bei Olympus wird klip und klar gesagt, man solle nichts machen, da die Datenbankstruktur etc pp noch NICHT fest ist.. keiner könnte auch sicher sagen, in welche Richtung es gehen wird (sowohl Projekt, als auch Olympus) und es kann durchaus sein, das so Datanbankprobleme ganz anders behandelt werden... was ist wenn ein Problem entsteht und dort Sachen die im Olympus in eine Spalte eingetragen jetzt werden zwei brauchen.. oder noch schlimmer umgekehrt.. könnte dann garantieren werden das der Konverter die Daten nimmt, analysiert, richtig teilt und dann in die Olympus DB einträgt ???
Gerade bei den Punkten, die sehr stark 'im Kern' liegen gibt es ZICH Ansätze es zu lösen.. Erstes Semester erste Vorlesung: Es gibt kein math Problem und kein Problem in der Informatik, welches nicht auf unendlich verschiedenen Möglichkeiten gelöst werden kann.. und bei der Anzahl von Mods/Projekten/etcpp die sich in der letzten Zeit angekündigt haben, sehe ich einfach nur, das es nachher eine Vielzahl von verschiedenen Systemen gibt, die kaum bis garnicht mehr kompatibel sind... was mir jetzt einfach sagt.. Finger weg..
Das Tolle daran, die einzige zwischen richtig und falsch unterscheidende Art zu sein, ist, dass wir uns immer genau die Regeln ausdenken können, die uns gerade in den Kram passen.
Douglas Adams - Die letzten ihrer Art
Naja wir gehen ja mit unserem Fork in eine andere Richtung. Wir wollen erstmal KEINE neuen Features, sondern erstmal ein fertiges Board auf die Beine stellen. Es wird auch sicherlich erstmal darauf geachtet, dass Kompatibilität zu phpBB 2.x und Olympus besteht, was aber später daraus wird lässt sich schlecht vorhersagen. Es wird sicherlich irgendwann der Punkt kommen, wo man für einen Wechsel zu Olympus auch einen Konverter benötigt... who knows...
@shwepsi:
niemand hat behauptet, dass sowas einfach wird. Genauer habe ich über diese Jump-Point-Geschichte auch noch nicht nachgedacht, das war nur eine spontane Idee, die ich lokal mal ausprobiert habe.
Auf Dauer würde sich bei den Mods aber der Spreu vom Weizen trennen. Unsauber programmierte Mods würden einfach aussterben, weil sie aufgrund der erschwerten Updates keiner mehr benutzt.
Jumppoints:
naja in gewissen teilen kann man sich das sicher wie das PCP oder das SecurityCenter vorstellen, man würde für die SQL-Jumppoints eben die felder abfragen und die zu berechnenden werte eben eine function schreiben die dann ausgeführt wird, je nach umfang müsste man eben das dann in einzelne dateien auslagern, andererseits könnte man sicher auch teile in die DB schreiben, wo dann nur noch die generalqueries abgefragt werden, statt alle dateien einzeln nach 1-2silbigen codeschnipseln zu durchforsten
in den meisten dateien könnte man sicher mit wenigen jumppoints an wichtigen stellen auskommen die man dann ansteuert, aber wie gesagt, in wie weit das ganze dann performant ist bliebe abzuwarten, bei ersetzen der bestehenden struktur währe aber sicher auch da schnell die grenze erreicht, wenn man nicht gerade die variable einfach überschreibt und dann eben doppelte arbeit macht
