WBCE CMS Forum

WBCE CMS – Way Better Content Editing.

Du bist nicht angemeldet.

#26 15.08.2015 08:20:05

norhei
Developer

Re: Wohin mit den Globalen Daten

Die Frage ist aber, wie wir es so gestalten. Das wir den PHP Einsteiger nicht völlig abhängen und trotzdem nicht irgendwelche nennenswerten Einschränkungen mit einbauen. 

Was das F3 betrifft finde ich es nicht so besonders das das Singleton Pattern so exessiv genutzt wird und der Autoloader gefällt mir nicht. Konstrukte wie:

$geo=\web\lib\Geoclass::instance();

erschliessen sich nicht jedem sofort und sind auch nicht wirklich praktischer als:

global $WB;  //mit einem Zentralen Datenarray.

Mann könnte sich allerdings schon bei solchen Libs bedienen, ist auf jeden Fall viel weniger Arbeit als alles selbst machen.
(man kann ja z.B. Statische Wrapper anbieten)

...alles garnicht so einfach.

Offline

#27 17.08.2015 07:59:54

badknight
Mitglied

Re: Wohin mit den Globalen Daten

rjgamer schrieb:

Gebt uns Modulentwickler eine Registry Klasse!  cool

https://github.com/hoaproject/Registry sowas wäre nett wink

Offline

#28 17.08.2015 09:16:16

norhei
Developer

Re: Wohin mit den Globalen Daten

Erklärt doch mal , warum viele so Heiss sind auf eine Reg Klasse sind ?
Wo liegen die Vorteile gegenüber zum Beispiel einem Globalen Array?
Vielleicht können die, die keine möchten dann nachvollziehen warum wir die möchten ...

Offline

#29 17.08.2015 10:30:11

easyuser
Mitglied

Re: Wohin mit den Globalen Daten

*hust*Daran wird schon gearbeitet: http://wiki.websitebaker.org/doku.php/dev/284/registry *hust*
Da gibt's auch die offizielle Erklärung, warum globale Array böse sind.

Offline

#30 17.08.2015 10:31:22

webbird
Administrator

Re: Wohin mit den Globalen Daten

Globaler Array -> Namespace Pollution
Klasse -> Ich hol mir nur das was ich brauche


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

Offline

#31 17.08.2015 10:38:48

easyuser
Mitglied

Re: Wohin mit den Globalen Daten

Achja, hier wird's evtl. ganz gut erklärt: http://alanstorm.com/magento_registry_singleton_tutorial

Am Besten ist es hier erklärt (leider auf Französisch, hier ggf. Translator benutzen, der haut nur die Codebeispiele durcheinander): http://www.croes.org/gerald/blog/les-registres-registry-en-php/361/

Beitrag geändert von easyuser (17.08.2015 10:45:18)

Offline

#32 18.08.2015 10:24:08

rjgamer
Developer

Re: Wohin mit den Globalen Daten

norhei schrieb:

Erklärt doch mal , warum viele so Heiss sind auf eine Reg Klasse sind ?
Wo liegen die Vorteile gegenüber zum Beispiel einem Globalen Array?
Vielleicht können die, die keine möchten dann nachvollziehen warum wir die möchten ...

Wer diese Frage stellt hat noch nie ein komplexes Modul mit Detailseiten etc. geschrieben! kiss

Als grosses Übel gelten für mich nämlich die PAGE_TITLE & Co Variablen.

Hier ein Beispiel, damit endlich alle Anti-Registry-Freunde wissen was an globalen Variablen kagge ist: Wie soll ich die Anforderung lösen wenn eine Detailseite eines Posts von einem News-Moduls a la news.php?post_id=1 einen anderen Seitentitel haben soll als "Unsere tolle News" wie es in der Seitenkonfiguriation eingestellt wurde? Die globale Variable PAGE_TITLE lässt sich ja nicht überschreiben! Somit muss ich als Modulentwickler einen üblen Workaround realisieren, der sich bis ins Template reinschleicht indem ich mit einer zweiten globalen Variable NEW_PAGE_TITLE den Seitentitel der Detailpage einfüge und dann im Template wie folgt überprüfe und ausgegeben:

if (defined('NEW_PAGE_TITLE')) {
 echo NEW_PAGE_TITLE;
} else {
 echo PAGE_TITLE;
}

Ist kagge oder? Mit einer Registry kann ich die Variable einfach überschreiben, sofern natürlich unserere Core-Entwickler die Variable nicht schreibgeschütz haben. Einige Variablen müssten nämlich in der Registry schreibgeschützt sein, wie beispielsweise Verzeichnis- und URL Angaben.

Gruss

PS: Das obere Beispiel mit dem News-Modul könnt ihr gerne in mein GamePortfolio-Modul von Free2play-Games.de adaptieren, bei dem ich genau dieses Problem hatte. Und noch einige mehr...

Beitrag geändert von rjgamer (18.08.2015 10:28:11)

Offline

#33 18.08.2015 10:27:35

webbird
Administrator

Re: Wohin mit den Globalen Daten

Das Beispiel finde ich jetzt nicht so gelungen, weil ich nicht der Ansicht bin, daß eine Superglobale wie PAGE_TITLE - egal ob es jetzt eine Konstante, eine Variable oder ein Array-Schlüssel ist - überschreibbar sein sollte. Hier gibt es andere Lösungsansätze, wie etwa Ralfs DropletsExtension. (Die kann nämlich den Seitentitel beeinflussen, ohne an den Konstanten rumfummeln zu müssen.) Die Frage ist doch eher, warum ich den Seitenheader im Template fest verdrahten muß, also warum da etwa

<title><?php echo PAGE_TITLE; ?></title>

drin stehen muß.


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

Offline

#34 18.08.2015 10:30:54

rjgamer
Developer

Re: Wohin mit den Globalen Daten

Hast recht, ich will einfach daraufhinweisen dass globale Variablen geschützt und unveränderbar sind. WBCE sollte aus meiner Sicht so bald wie möglich eine saubere Lösung liefern. Entweder wie meinen Ansatz oder bisschen restriktiver. Aber dass eine Registry sauberer ist als dutzende von globalen Variablen sollte jedem klar sein. Schon nur um die Übersicht zu behalten.

Anmerkung: Die neue WB Version soll doch auch so ein Adapter/Registry Klässchen liefern... wobei die Devs ja nicht auf meine Fragen antworten.

Beitrag geändert von rjgamer (18.08.2015 10:32:10)

Offline

#35 18.08.2015 13:42:31

norhei
Developer

Re: Wohin mit den Globalen Daten

Die neue WB Version soll doch auch so ein Adapter/Registry Klässchen liefern... wobei die Devs ja nicht auf meine Fragen antworten.

Du meinst bei WB Classic?  Nee, die antworten nicht.

Das wir hier eine Zentrale für sowas machen ist schon klar , nicht so klar ist welche. Selbst bei Klassen basierten Lösungen gibt es eine Menge Möglichkeiten.

Ich möchte noch mal darauf hinweisen warum dieser Thread gestartet wurde. Es ging darum die Vor und Nachteile verschiedener Lösungen für eine Zentrale Datenverwaltung zu erörtern. Also zum Beispiel die verschiedenen Modelle die ich im Eingangsthread erörtert habe. Es ging nicht darum ob eine solche Lösung kommt . Nur soll sie halt möglichst einfach sein, damit keiner auf der Strecke bleibt. Und vielleicht auch alle verstehen warum so etwas sinnvoll ist.

Vieleicht noch einige Erklärungen warum wir überhaupt ein Problem haben, wir haben zur Zeit eine Unmenge Konstanten , die aber nicht einheitlich/sinnvoll benannt sind des weiteren haben wir jede Menge Globale Variablen für die das gleiche gilt. Dokumantation dazu existiert kaum mehr.
Manche Dinge davon sind obendrein noch sicherheitstechnisch ein Graus , zum Beispiel die konstanten mit den Zugangsdaten zur DB(Variablen könnte man nach einem Verbindungsaufbau löschen) Wenn ich in einer Funktion/Klasse auf die Globalen Variablen Zugreifen möchte muss ich entweder alle Vars einzeln mit gobal holen, oder gleich den ganzen $_GLOBALS Array reinholen. Selbst nur ein einfacher zentraler Array sagen wir mal $WB wäre besser.
Mann muss nur einmal global einsetzen und hat nur alle WB relevanten Variablen importiert. Zudem wenn jetzt jemand nur als Beispiel die Variable $database in seinem Modul oder in einer externen Anwendung nutzt (und zwar nicht um sich mit der WB eigenen DB zu verbinden sondern mit seiner eigenen), dann geht ab der Stelle jede WB Datenbank Abfrage nicht mehr. Wegen solcher Sachen ist bei mir zum Beispiel eine Forum Integration mal gescheitert.  Diese ganzen Variablen/Konstanten zu vereinheitlichen bringt auch jede Menge Probleme  mit sich und Probleme bedeuten Zeit und Aufwand.
Auch dabei müssen auf lange Sicht einfach mal Variablen in Modulen angepasst werden. . Dazu kommt noch das jede Verbesserung immer neue Variablen und Konstanten mitbringt, die dann nochmal wieder anders ausschauen. Das führt letzten Endes dazu das die Core Entwickler keine Chance mehr haben den Knoten aufzulösen und einfach aufgeben. Ich habe hier die letzten Tage auch einige Schreikrämpfe aus Verzweiflung gehabt.

Zurück zum Hauptthema , gibt es Lösungsansätze (möglicherweise auch ungewöhnliche) die sich durch besondere Einfacheit auszeichnen ?
Einer der Gedanken war einfach eine Instanzierte Registry Klasse zu nutzen und die mit globalen Funktionen zu kapseln. WBget(), WBset() Damit könnten andere Klasssen diese Klasse erweitern(extend) und nutzen. Wenn man möchte das alles per Autoloader funktioniert kann man auch eine Facade Klasse setzen, dann hat WB::get(), WB::set()  und trotzdem eine richtig instanzierte Registry mit allen Vorteilen. Zum beispiel könnte ein Modul seine Eigene Facade mitbringen NEWS::get(), NEWS::set() in der es nur seine Daten kapseln kann.  Und mann müsste sich nicht mit Singleton oder statischen Klassen belasten.

Und ganz wichtig !!! Die alten Vars und Konstanten bleiben definitiv noch eine Weile erhalten. Und wenn jemand sein Modul umstellen möchte sind sich hier Die, die das verzapft haben, auch nicht zu schön um zu helfen. Sprich sowas wie "Das Coreteam hat nichts mit den Modulen zu tun *naserümpf*" denke ich werden wir hier nicht erleben!

Offline

#36 18.08.2015 13:47:11

webbird
Administrator

Re: Wohin mit den Globalen Daten

Zu "keine Dokumentation": Alle Einstellungen aus der Settings-Tabelle werden als Konstanten gesetzt, ansonsten einfach mal ein grep define bzw. grep constant (wobei letzteres wohl kaum vorkommen dürfte).

Es sind gar nicht mal so viele, wie es scheint. big_smile

Allerdings stimmt es, daß einiges doppelt und dreifach gemacht wird, etwa die Seiten-ID. (Konstante PAGE_ID, Superglobale $page_id, Objekteigenschaft $wb->page...)


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

Offline

#37 18.08.2015 14:18:25

easyuser
Mitglied

Re: Wohin mit den Globalen Daten

@norhei:
An sich ist das Ganze recht einfach.
Ich habe eine Klasse (meinetwegen "WBRegistry"), einen Getter und einen Setter. Dann das Ganze noch in einem Singleton gekapselt.
Natürlich kann man das jetzt deutlich erweitern, aber ein theoretischer Ansatz wäre ohne Gewähr auf Richtigkeit usw.:

[== PHP ==]
<?php
/**
 * @filecontent The WBRegistry
 * @author blubb
 */
class WBRegistry {
	
	private static $instance = null;
	private $wbRegistry = array();

	/**
         * @description Das Singleton. 
	 *              Zu verwenden: $wbRegistry = WBRegistry::getInstance();
	 *
	 * @param
	 * @returns instance
	 */
	public static function getInstance() {
		if(self::$instance === null) {
			self::$instance = new WBRegistry();
		}
		return self::$instance;
	}

	private function __construct() {}
	private function __clone() {}

	/**
         * @description Der Setter.
	 *
	 * @param key {String}
	 * @param value {String}
	 * @returns 
	 */
	public function set($key, $value) {
		if (isset($this->wbRegistry[$key])) {
			throw new Exception("There is already an entry for key " . $key);
		}
		$this->wbRegistry[$key] = $value;
	}
	
	/**
         * @description Der Getter.
	 *
	 * @param key {String}
	 * @returns value {String}
	 */
	public function get($key) {
		if (!isset($this->wbRegistry[$key])) {
			throw new Exception("There is no entry for key " . $key);
		}
		return $this->wbRegistry[$key];
	}
}
?>

Zu verwenden ist das Ganze dann z.B. wie folgt, also Beispiel mal, wie man in einem Modul PDO verwendet, ohne die Datenbankparameter in der Registry zu ändern:

[== PHP ==]
<?php
   // Importiere die Registry
   require_once('WBRegistry.php');

   try {
      require_once('WBIniConfiguration.php');

      // Hole die Instanz
      $wbRegistry = WBRegistry::getInstance();
      
      // Lade erstmal die Core-Registry
      $wbRegistry->set('config', new WBIniConfiguration('config.ini.php'));
      
      // Lade dann die Datenbankverbindungs-Parameter
      $db = $wbRegistry->get('config')->getSection('database');
      
      // Jetzt gibt's mal PDO-SQL-String (oder was auch immer)
      $pdoString = "mysql:host=" . $db['host'] . ";dbname=" . $db['name'];
      
      // Initialisiere die PDO-Datenbankverbindung *****
      $pdo = new PDO($pdoString, $db['user'], $db['pwd']);
      
      // Und füge das alles zur Registry hinzu.
      $wbRegistry->set('pdo', $pdo);
   } catch(Exception $e) {
      echo $e->getMessage();
   }
?>

***** -> Bitte keine Diskussion bzgl. Sicherheit, das ist ein reines Beispiel!

Beitrag geändert von easyuser (18.08.2015 14:28:03)

Offline

Fußzeile des Forums

up