WBCE CMS Forum

norhei

Developer

Wohin mit den Globalen Daten

Bei den Letzten Bastelaktionen ist mir mal wieder der Bunte Mix aufgefallen wo alles Globales gespeichert wird.

Wollte mal eine kleine Diskussion anstoßen wo wir in Zukunft mit den globalen Daten hin sollen.

1. Konstanten
Vorteile: 
Nicht mehr  zu ändern ,
extrem gute globale Verfügbarkeit (kein einbinden usw.)

Nachteile: Nicht mehr zu ändern.

2. Register Klasse mit instanz
Vorteile: 
Einfacher Zugriff mit $reg->myvar
Kann geändert werden.
Wenn was geändert wird was nicht sollte kann er eine Exeption werfen.

Nachteile: 
Der Handler muss auch noch mit "Global" in Funktionen und Klassen geholt werden.

3. Globaler Array
Vorteile :
Kann geändert werden
Aufruf einfach mit $wb['myvar'].

Nachteile:
Keine Exeption bei Änderung von Sachen die man nicht geändert möchte.
Muss mit "Global" in jede Klasse /Funktion geholt werden.

4. Statische Klasse
Vorteile:
Wie Konstanten verfügbar überall.
Könnte auch einen globalen Array bedienen.
Kann Warnungen ausgeben.

Nachteile:
Aufruf etwas unschöner  $Data::get('myvar');  und  $Data::set('myvar', something);

Kennt Noch jemand eine Möglichkeit , bzw wie habt ihr das in euren Forks gelöst ?

Beitrag geändert von norhei (03.08.2015 11:32:22)

webbird

Administrator

Re: Wohin mit den Globalen Daten

Wir haben noch den bunten Mix, sind aber auf dem Weg zu Lösung 4. Die Klasse gibt's auch schon. Wegen der Rückwärtskompatibilität kommt man von den Konstanten halt nicht so ohne weiteres weg.

---

Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

webbird

Administrator

Re: Wohin mit den Globalen Daten

Noch eine Möglichkeit: Pimple.

---

Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

norhei

Developer

Re: Wohin mit den Globalen Daten

Die Alten Vars und Konstanten müssen halt noch eine Weile drin bleiben.

Pimple???

ahh, habs .
http://pimple.sensiolabs.org/

Auf der Abstraktionsebene werden aber viele Aussteigen.

Warum habt Ihr euch dagegen entschieden ?

Beitrag geändert von norhei (03.08.2015 11:59:49)

florian

Administrator

Re: Wohin mit den Globalen Daten

Hallo,

ich bitte zu berücksichtigen, dass die Abwärtskompatibilität gewährleistet sein muss. Ich will hier kein Pseudo-WB à la 2.8.4, wo nichts mehr passt und funktioniert. Ich will auch weiterhin auf PAGE_ID usw. zugreifen können und nicht irgendwelche bescheuerten $wb:[->(id)::]{1231}?.._\-Verrenkungen machen.

---

Wir Benötigen: Cents, Euros... jetzt spenden!

webbird

Administrator

Re: Wohin mit den Globalen Daten

Warum habt Ihr euch dagegen entschieden ?

Naja, war so ein bißchen Kanonen auf Spatzen. Ich hab mal damit rumexperimentiert und war dann der Meinung, die einfache Eigenlösung tut's auch.

@florian: Den Ansatz verfolgen wir bei BC auch, trotzdem sollte man den Wildwuchs eindämmen und zumindest da, wo es um Interna geht, weg von den Konstanten. Die wurden früher halt gern genommen, weil es einfach ist und es auch keine Alternativen gab. Das ist heute anders.

Die Registry-Klasse in BC setzt _auch_ Konstanten, der Anwender merkt nichts davon, daß sich unter der Haube was verändert hat. Dem geneigten, fortschrittlichen Developer ist dennoch eine Schnittstelle gegeben, die er nutzen kann.

Ich mach's halt tendenziell gern allen recht, soweit es geht, und halte mich nicht sklavisch an irgendwelche neuen Trends. Das heißt aber trotzdem nicht, daß man ewig im Gestern verweilen muß. Bei vielen hört es sich halt so an, als gäbe es nur entweder oder, bei DV beispielsweise. Das ist aber Unsinn. Drum schreib ich meine Klassen auch immer so, daß man sie sowohl instanziieren als auch statisch benutzen kann. (Es sei denn, man braucht wirklich objektbezogene Daten, aber das dürfte für die meisten jetzt zu weit ins Eingemachte gehen.)

---

Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

grindbatzn

Gast

Re: Wohin mit den Globalen Daten

Was ist eigentlich schlecht an Konstanten? Ich hab oft den eindruck, die sind irgendwie Pfui..

Wenn ich etwas generell verfügbar haben will, und es darf keinesfalls geändert werden - dann tuts ja genau das.
PAGE_ID zB. Es gibt genug Module, die die $page_id ändern (macht oft mal Ärger) - die PAGE_ID hab ich immer gültig zur Hand.

webbird

Administrator

Re: Wohin mit den Globalen Daten

Kurz gesagt: Namespace pollution.

Wenn man es mit einem komplexen System zu tun hat - und ein CMS kann man durchaus komplex nennen -, muß man schon ziemlich detaillierte Namenskonventionen haben, damit sich die Konstanten nicht in die Quere kommen. Mal angenommen, irgendein Modulautor kommt auf die Idee, er möchte eine Konstante XY haben, die irgendeine Info speichert - so weit, so gut. Nun kommt der nächste Modulautor um die Ecke und hat dummerweise genau die gleiche Idee. Auch in Bezug auf den Namen der Konstanten. Hoppla!

Auch bei CSS ein beliebtes Problem, wenn mehrere Modulautoren eine Klasse "content" benutzen und die nicht sauber referenzieren. Einmal kurz .content im CSS verhackstückt und schon kann es passieren, daß die komplette Seite verhunzt ist.

---

Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

webbird

Administrator

Re: Wohin mit den Globalen Daten

Nachtrag: Das ist eben das Problem mit der Verallgemeinerung. Nichts ist grundsätzlich gut oder schlecht, man muß es im Zusammenhang sehen. Wenn ich heute ein CMS "from scratch" schreiben würde, würde ich keine globalen Konstanten benutzen. WB hat aber eine Vorgeschichte. Und sauber dokumentiert und begründet sind globale Konstanten eben auch nicht ausschließlich böse und pfui. Doof ist halt nur, daß viele Entwickler nicht so genau differenzieren...

---

Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

grindbatzn

Gast

Re: Wohin mit den Globalen Daten

Es gehört wohl zum Grundwissen, dass man für Variable und Konstante aussagekräftige Namen verwendet. Außer Dinge wie $i - die immer nur temporär gelten und grundsätzlich initialisiert werden müssen.
Das gilt in allen Programmiersprachen und da lösen auch Kanonenrohre keine Probleme.

Bei Modul.css natürlich das gleiche. Es kommt vor, dass manchmal etwas gleich heißt, aber das muss man eben ändern. Ist ja nicht in Stein gemeißelt.

norhei

Developer

Re: Wohin mit den Globalen Daten

Ich mach's halt tendenziell gern allen recht, soweit es geht, und halte mich nicht sklavisch an irgendwelche neuen Trends.

+1

@grindbatzn
Generell habe ich den Thread ins Leben gerufen, weil ich halt das Problem hatte wohin mit meinen Daten. Konstanten finde ich persönlich immer recht nützlich, genau wie du sagtest, wenn es darum geht etwas festzulegen was später nicht mehr geändert wird. Und ich habe erst einmal gar nichts ausgeschossen und nur Möglichkeiten aufgezählt.

Konstanten ein weiterer Vorteil: Habe letztens gelesen , ist eine Konstante im lokalen Namespace nicht vorhanden, wird auf die Globale zurückgegriffen. Ich sehe das als Vorteil.

Allerdings sind die Konstanten in WB auf die schlechtes mögliche Weise implementiert, so das Kollisionen nicht unwahrscheinlich sind. Beispiel
PAGE_ID  / WB_URL . Die dummen Dinger sind nicht einheitlich und es gibt Teilweise viele Stellen an denen ein und die selbe Sache gespeichert ist.  Und teilweise noch mit unterschiedlichen Werten.  Sinnvoll wäre z.B. WB_PAGE

Dann ist noch die Frage was macht man mit Werten, die Sich ändern können. Zum beispiel ein Array in den die Module alle Ihre JAVAScripte reinlegen können , und der dann am Ende  im Template gerendert würde.

Oder ein Array der die Daten aller aktiven Module enthält, wo tu ich den hin ? In einer Konstanten kann ich keinen Array Speichern, höchstens serialisiert.

Globale Variablen könte man auch in einem zentralen Array speichern, dann müsste man in jedem Fall nur noch eine Variable per  "global $WB;" holen und nicht mehrere. (global $database; global $page_id;.....)

Das Coole an einer Klasse wäre, das man die alten Werte beim setzen der neuen Werte gleich mit erstellen kann.

$variable=$Ge::t('variable');
$Se::t('variable',$variable) ;

Währe gegenüber;
$variable=$_GLOBAL['variable'] ;
$_GLOBAL['variable'] = $variable;

Auch nicht wirklich Schlechter.

Zumal Grade in den Modulen die meisten wichtigen Variablen sowiso vom Core in den Namensraum geholt werden, bevor die Modify.php überhaupt includiert wird. Sprich, das ist nicht das Problem des Modulauthors. 

Wie gesagt Ich wollte mich mal umhören und schauen was es So gibt, und was alle dazu denken.

Beitrag geändert von norhei (03.08.2015 15:09:24)

webbird

Administrator

Re: Wohin mit den Globalen Daten

Es tut eigentlich auch nicht Not, die gesamten Einstellungen aus der Settings-Tabelle in globalen Konstanten - und die sind nun wirklich global - zu verwursten, bloß weil es ja mal sein könnte, daß die irgendwo gebraucht wird. Eine Klasse hat auch hier wieder den Vorteil, daß sie die Einstellungen bei Bedarf holen kann, ohne daß jeder Dreck von vornherein initialisiert wird, ohne daß man ihn überhaupt braucht. Ein

Registry::get('mediadirectory')

kann beispielsweise viele schöne Dinge tun:

* Die Einstellung aus der DB holen, wenn das bisher noch nicht der Fall war
* Die Schreibweise ignorieren, so daß 'MediaDirectory', 'mediaDirectory' oder auch 'MEDIADIRECTORY' einfach blind funktionieren
* Optional den Variablentyp prüfen (sowas wie Registry::get('meineeinstellung','boolean') liefert false, falls in 'meineeinstellung' ein String oder was anderes Unerwartetes steht)

Allerdings bleibt das Problem der Rückwärtskompatibilität, Klasse hin oder her. Daher kann eine Klasse erst mal nur eine Ergänzung sein, und bis auf weiteres kein Ersatz.

---

Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

norhei

Developer

Re: Wohin mit den Globalen Daten

Allerdings bleibt das Problem der Rückwärtskompatibilität, Klasse hin oder her. Daher kann eine Klasse erst mal nur eine Ergänzung sein, und bis auf weiteres kein Ersatz.

Jep, so hatte ich das auch gedacht.

Vielleicht wenigstens die Konstanten mal vereinheitlichen, und Dokumentieren, So das die ganz Alten irgendwann einfach mal raus können.
Nu sind wir uns hier auch nicht zu schön um einem Modul, das wegen einer Änderung etwas stolpert wieder auf die Beine zu helfen.

webbird

Administrator

Re: Wohin mit den Globalen Daten

Wus? "I'm too sexy for this forum..."

---

Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

norhei

Developer

Re: Wohin mit den Globalen Daten

Noch ein Nachteil von Konstanten, man kann keine Objekte drinn speichern

Mir ist da noch eine 5. Idee gekommen , eine globale Funktion die alles weitere Kapselt und halt eben Global ist.
Was sich dann dahinter versteckt kann dem Nutzer egal sein(Klasse mit Methoden oder was auch immer).

$varname=wb('varname');//get
wb('varname', $varname);//set

$Text="bla ". wb('varname'). "weiterer Text";

Nur so ein Gedanke, Damit könnte man auch eine instanzierte Registry Klasse richtig global machen und einfach wärs obendrein.
Und Die Klasse, könnte sich dann um alles weitere kümmern.

webbird

Administrator

Re: Wohin mit den Globalen Daten

Edit: Hier stand vorher folgender Beitrag von grindbatzn:

So ganz verstehe ich den Sinn der Überlegungen nicht.

Das ist alles das "unter der Haube", das wir von WB schon Jahre lang hören. Und das den Durchschnittsuser - und auch den Durchschnitts-Modul-Bastler - null interessiert.
Sicherheitsaspekte sind nur theoretisch betroffen (klar, kann man sich was zusammenreimen - aber wie hoch ist die Wahrscheinlichkeit?)

Da ich diesen wegen des zweiten Abschnitts abgetrennt habe, ist er nun hier zu finden: https://forum.wbce.org/viewtopic.php?id=68

Du hast sicherlich eine andere Sichtweise auf den Core, ebenso wie florian. Das heißt aber nicht, daß man nicht "unter der Haube" auch was optimieren darf, selbst dann, wenn es nicht sichtbar ist. An dieser Stelle legt man den Grundstein für die Zukunftssicherheit. Es ist durchaus denkbar, daß die globalen Konstanten irgendwann abgeschafft werden - vor allem, wenn man sich die Kernfeatures von PHP 7 anschaut.

---

Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

norhei

Developer

Re: Wohin mit den Globalen Daten

Also erst mal sind wir hier in Entwicklung/Development WBCE Core im Forum.
Ich glaube das Thema passt also.

Ich kann nicht einfach duzende von neuen Variablen /Konstanten erstellen ohne mir vielleicht vorher Gedanken darüber zu machen wie ich die verwalte.
Wenn Wir einfach weitermachen würden wie Vorher , könnte irgendwann keiner mehr am Core was ändern ohne das was anderes Kaputt geht.

Meine Intention war Ideen zu sammeln und Meinungen zu hören. Auch am liebsten würde ich meine Kontanten behalten ist eine Meinung und zwar keine schlechte. Problematischer sind eigentlich die Variablen , die so rumgeistern und oft völlig undokumentiert und nicht Standarisiert. Aber auch bei den Konstanten wär es schön wenn die nicht völlig unterschiedliche Namen hätten. Es blickt sonst einfach keiner mehr durch !

Eine der einfachsten Lösungen wäre einfach ein Globaler Array sagen wir mal "$WB" in dem man diese herumstreunenden Variablen sammeln könnte.
Aber es gibt halt noch viele andere Möglichkeiten und ich versuche die zu finden, die die Wenigsten Kopfschmerzen bereitet.

Das das Problem akut ist, sieht man schon sehr schön daran, das DV nur ganz extrem langsam bis gar nicht voran kommt.
Sprich wenn wir ohne nachzudenken einfach Variablen, Konstanten und funktionen zusätzlich reinzimmern, wird das Projekt in relativ kurzer Zeit unwartbar werden. Denk einmal An deine Probleme mit Topics. Ab einer bestimmten Projektgröße stößt diese Art zu Programmieren einfach an Ihre Grenzen.  ICh bin selber kein Fanatischer Paradigmen Reiter nur irgendwann muss man aufräumen Sortieren und Bündeln .     

So nebenbei:
Erst vor kurzem ist mir aufgefallen, dass im Menü Seiten ausgelassen werden, wenn sie keine aktiven Abschnitte haben. Das generiert bei jedem Seitenaufruf tw. 100e Datenbank-Abfragen zusätzlich, bei einer gefühlten Wahrscheinlichkeit von 1/10Mio, dass sich dadurch etwas ändert.
Das sind NICHT die Art von Features, die ich mir von "unter der Haube" erwarten würde.

Sei doch bitte So lieb und stell das bei Bugreports ein.   Welches Menu meinst Du ? show_menu2() ? Wie hast Du das festgestellt, wie kann ich das Reproduzieren. Dann nimmt sich Jemand der Sache an.

webbird

Administrator

Re: Wohin mit den Globalen Daten

Ich hab das mal abgetrennt.

http://forum.wbce.org/viewtopic.php?id=68

Leider ist damit auch chios Meinung zu diesem Thread mit rübergewandert, ich weiß nicht, ob und wie man einen einzelnen _Beitrag_ aufteilen kann. Das geht wohl nur mit ganzen Beiträgen.

---

Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

florian

Administrator

Re: Wohin mit den Globalen Daten

Das nimmt hier langsam Formen an... ich glaube, hier wird die Sphäre des bloßen WB-Bugfixings endgültig verlassen. Here Ziele mag man sich stecken, ich gebe aber zu bedenken, dass die Anzahl der Entwickler hier derzeit doch sehr überschaubar ist. Konkret: norhei, bitte schalte mal einen Gang runter. Mir ist es erst einmal wichtig, eine zuverlässige, benutzerfreundliche, funktionierende WBCE-1.0 an den Start zu bringen. Dann sollten wir erst einmal ein Weilchen abwarten, wie groß die Akzeptanz für dieses neue WB ist und wie viele Nutzer + Modulentwickler wir dafür gewinnen können. Und erst dann ist es mMn sinnvoll, über grundlegende Veränderungen nachzudenken.
Es gibt bereits zwei Forks, die eigentlich nur aus politischen Gründen noch nicht WB abgelöst haben: BlackCat und Lepton. Wenn WBCE zum dritten tollen, aber leider nicht mehr WB-kompatiblen Fork degeneriert, nehmen sich WBCE, BC und L+ gegenseitig die Butter vom Brot, während WB classic fröhlich weiter herumdilettiert und -diktiert. Das kann's doch nun auch nicht sein.

---

Wir Benötigen: Cents, Euros... jetzt spenden!

webbird

Administrator

Re: Wohin mit den Globalen Daten

Ich persönlich fänd's auch total doof, noch ein BC zu bauen.

---

Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

cwsoft

Mitglied

Re: Wohin mit den Globalen Daten

@florian: Denke die Vorschläge sind eher längerfristig und unter der Haube (abwärtskompatibel). Aktuell sehe ich das aber auch so. Konstanten bleiben erstmal und die Abstraktion mit einer Config-Klasse ist erstmal Zukunftsmusik. Hat jahrelang funktioniert, da kommte es jetzt auf ein Jahr mehr oder weniger auch nicht an.

---

Account inactive since 2018/11/17.

webbird

Administrator

Re: Wohin mit den Globalen Daten

Wenn man im WB-Umfeld den Begriff "Framework" fallenläßt, wird man ja sofort gesteinigt, aber trotzdem mal: Man muß ja nicht immer alles selbst neu erfinden. Komischerweise kommt keiner auf die Idee, für WB eine eigene Template Engine zu schreiben, bei anderen Dingen muß es aber unbedingt was Eigenes sein.

Nur der Erwähnung halber: Von allen Frameworks, die ich mir angeschaut habe, mag ich F3 (Fat Free Framework) am liebsten. Das ist extrem schlank und kann dafür schon eine unglaubliche Menge. Z.B. - und damit zurück zur Topic - hat es eine Registry.

---

Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

norhei

Developer

Re: Wohin mit den Globalen Daten

Wenn ich es Problemlos wollte würde ich PW nehmen. Allerdings hat WB seinen eigenen Charme , Die Sache mit den Pagefiles ist ungewöhnlich, lässt sich aber auch extrem gut zum cachen nutzen und ist ansonsten auch nicht schlecht. Ein Redirect zum Sprachwechsel ist irgendwo steinalt, aber auch so einfach das es fast schon genial ist.  Keine Template Engine nutzen zu müssen finde ich auch geil, da freue ich mich auch bei PW drüber, das ich das nutzen kann , aber nicht muss.  (eine Einstiegshürde weniger) .

CMS auf Framework Basis gibt es Tausende warum also nicht einmal vieles anders machen. Zum Beispiel könnte ich mir ganz gut eine nur schwach miteinander gekoppelte(loose coupling) Sammlung von Bibliotheken vorstellen. Das diese auch teilweise OOP Funktionalität nutzen lässt sich eigentlich nicht mehr vermeiden und ist auch nicht schlecht.

Eine brauchbare Registy kann man auch in anderen Projekten benutzen. Die aus anderen Frameworks sind meistens auch stark mit dem Framework verknüpft , was dazu führt das an dann irgendwann doch das gesamte Framework mit drin hat. und Framework CMS gibt es wie schon gesagt Tausendfach.

In jedem Fall sollte sich WB weiter von der Masse abheben, andere Wege gehen , sonst ist das alles völlig sinnlos.

webbird

Administrator

Re: Wohin mit den Globalen Daten

Schau Dir das F3 einfach mal an, und sei es nur zu Lernzwecken. Ich jedenfalls habe viel draus gelernt.

---

Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

rjgamer

Mitglied

Re: Wohin mit den Globalen Daten

Gebt uns Modulentwickler eine Registry Klasse! 

---

Neoflow | Fraggy Backend Theme