Ich würde gerne manche Methoden, die man doch immer wieder nutzt, in einen Trait auslagern. Dabei möchte ich aber dennoch eine Ausgabe im Debug Fenster erzeugen wenn in der Methode etwas nicht funktionieren sollte. Weiterhin würde ich SendDebug auch gerne in Klassen nutzten, die unterhalb von libs liegen und keine Unterklasse von IPSModule darstellen.
Ist das grundsätzlich möglich, wenn ja wie muss der Code aussehen um von einem Trait oder andere Klasse eine Ausgabe ins Debug Fenster zu machen?
Vielen Dank für die Info d.h. bei einem Trait geht das wie immer, wie sieht das bei externen Klassen aus? Gibt es da auch eine Möglichkeit etwas im Debug Fenster auszugeben oder muss eine Klasse immer eine Unterklasse von IPSModule sein?
Muss von ipsmodule geerbt werden, sonst funktioniert das nicht.
Ein Grund warum ich auch gerne traits nutze. Aber wir haben jetzt schon die ersten Fehler im Forum gesehen, wo durch die doppelten Trait-Namen es zu Fehlern kommt.
Michael
Immer dann wenn du zwei oder mehr Instanzen von verschiedenen Modulen in einem Script ansprichst; wo die Traits der verschiedenen Module den gleichen Namen nutzen.
Michael
Dein BufferHelper zum Beispiel nutze ich auch mit dem selben Namen.
Kann man also nur verhindern, wenn man dort ein Präfix nutzen würde?
Könnte man ja das Präfix vom Modul vorschreiben, oder?
Ja geht.
Irgendwie aber auch blöd, ich will auf lange Sicht meine Traits Vereinheitlichen und als Submodule einbinden.
Klar, könnte ich jetzt eine eigene Klasse nutzen, welche alle Traits lädt und ipsmodule erbt.
Aber dann Schleife ich immer den ganzen Overhead mit, auch wenn ich z.B. nur einen Traits wie DebugHelper nutzen möchte.
Bin da selber noch unschlüssig wie der beste Weg wäre.
Wenn IPS anstatt nur die PHP-Klasse zu nutzen, auch jedem Modul einen Namespace geben könnte, wäre das eine Lösung.
Michael
Gerade Traits für Buffer, Debug, Variablen etc. wären cool einheitlich als Submodule zu haben.
Solltest du das tun, könnte sie ja wieder jeder ohne Probleme einbinden, ich würde mich freuen.
Ja eben nicht.
Dann knallt es.
Da die Dateien ja unterschiedliche Pfade haben, aber den gleichen Trait-Namen gibt dass dann Fatal-Error
Für PHP sind das verschiedene Dateien (auch wenn sie aus dem gleichen Repro kommen).
Michael
wenn ich in einem Modul einen trait innerhalb eines Moduls include und ein Trait hat z.B. den Namen Notifications … so wird dieser ja Bestandteil des Moduls.
// Include all files in helper folder
include_once __DIR__ . '/helper/autoload.php';
class TestModuleOne extends IPSModule
{
// Helper
use Notifications;
.....
Wenn ich in einem weiteren Modul das selbe mache…
// Include all files in helper folder
include_once __DIR__ . '/helper/autoload.php';
class TestModuleTwo extends IPSModule
{
// Helper
use Notifications;
.....
im helper Ordner eines jedem Moduls befindet sich die Datei notifications.php mit folgendem Inhalt:
<?php
// Declare
declare(strict_types=1);
trait Notifications
{
//#################### Notifications
public function Notification(string $Text)
{
// do something
}
}
tritt dann auch der genannte Fehler auf? Es befindet sich ja alles innerhalb des Moduls.
Oder tritt dies auf, wenn es nur einen „globalen“ Trait Notifications gibt und dieser in beiden Modulen verwendet werden soll?
Also bei mir geht es primär nicht um Vererbung, sondern soll für mich zu einem übersichtlicheren Code verhelfen.
Ich habe durch etwas externen Input (dank an Paresy) jetzt eine Lösung für mich gefunden.
Ist aber sehr Tricky und man hat schnell einen Knoten im Kopf.
Überlegung ist alle Traits mit einem Namespace zu nutzen.
namespace bvip;
/**
* DebugHelper ergänzt SendDebug um die Möglichkeit Array und Objekte auszugeben.
*/
trait DebugHelper
{
...
require_once __DIR__ . '/../libs/helper/DebugHelper.php';
class BVIPDiscovery extends IPSModule
{
use bvip\DebugHelper,
bvip\BufferHelper;
Da ich aber irgendwann alle gleichen Traits als Submodul für alle meine Module nutzen möchte, sobald der Store dies unterstützt, hat man wieder das gleiche Problem.
Da dann mehrere Dateien mit den gleichen NS\Trait auf dem Dateisystem liegen.
Somit muss beim laden der externen Traits ein individueller Namespace benutzt werden.
/**
* DebugHelper ergänzt SendDebug um die Möglichkeit Array und Objekte auszugeben.
*/
trait DebugHelper
{
...
Das wird dann noch komplizierter, wenn die Traits irgendwo Klassen benutzen. Dann wird versucht die Klasse mit dem NS zu finden.
Oder wenn man weitere Vererbung mit anderen Klassen nutzen. Zum Beispiel wenn vier Module (hier sind Module innerhalb einer Library gemeint) die gleiche Code-Basis einer Basisklasse nutzen sollen, welche wiederum Traits nutzen und von ipsmodule erben muss.