Instanz Klassen Objekte vorab mit statischen variablen der Klasse konfigurieren für welche Szenarien Sinnvoll.

[MB]

Moin Community,

ich möchte wissen, ob man die Klasse Foo, aus der eine Instanz erzeug wird (z.B. $foo = new Foo( $fuz )), vorab mit statischen Methoden Foo::bar( $baz ) dieser Klasse Foo konfigurieren soll, bevor die Klasse Foo instanziiert wird. Man erspare sich einen zweiten Parameter bei der Instanziierung von Foo (z.B. $foo = new Foo( $fuz, $baz )).

vlg MB

ps: hoffe es ist verständlich. Wenn nicht, dann erklärt mir, wie ich es verständlicher machen kann. Jeder vorschlage ist herzlich willkommen 😉!!!

[pl]

Machbar ist alles. Aber speziell das was Du hier ansprichst ist der kürzeste Weg ins Chaos. Es verletzt die OOP Charta zur Frage der Kapselung dermaßen, daß es eine Wartung von Programmen fast unmöglich macht und auch das Debugging erschwert.

Meine Empfehlung:

1. prüfe ob defaults gesetzt werden können,
2. bestimme das Verhalten von Instanzen außschließlich über die in der Instanz selbst gekapselten Properties

Und im Grunde genommen braucht OOP überhaupt keine statisch deklarierte Typen.

Freundschaft 😉

[MB]

moin pl,

guter punkt. Ich habe gesehen das Klassen die eine Instanz erzeugen, intern sich schon konfigiruert haben.

class Foo() {
  private $fuz;
  function __construct() {
    $this->fuz = Bar::get( 'baz' );
    /* Code */
  }
}

Du siehst, das ich die Konfiguration in eine andere Klasse Bar ausgelagert habe um mit Foo arbeiten zukönnen. Die Konfiguration würde sich stehts ändern, deswegen ist es, für mich, weniger Sinnvoll, diese fuz Kofiguration in die Klasse Foo zu übertragen. Deswegen die Frage 😉. Wenn du andere professionelle Lösungen zu diesem Problem hast oder begründen kannst, warum du es so im Property machst…

class Foo() {
  private $fuz = 'fuz';
  function __construct() {
    /* Code */
  }
}

… dann erleucht mich :).

vlg MB

ps: Für alle: Foo-Beispiel ist nur ein Beispiel für das komplexe Problem

[pl]

Natürlich kannst Du eine Konfiguration oder andere vogelwilde Datentypen auf diese Art und Weise in eine Instanz hineinschmacken. Solange das funktionale Verhalten der Instanz damit nicht bestimmt wird, ist sowas unschädlich im Sinne meiner ersten Anmerkung.

Es ist sogar sehr nützlich, wenn sämtliche Nutzdaten an der Instanz hängen, da sind sie in jeder Methode ohne Umschweife verfügbar.

Freundschaft 😉

[MB]

Sorry ich wollte dir und allen eigentlich sowas zeigen. Ich schreibst nochmal oben dran: danke das du mich erinnert hast.

[MB]

class Config {
  public const FUZ = 'fuz';
}

class Foo {
  private $fuz;
  public function __construct() {
    $this->fuz = self::$fuz;
  }
  private static function setFuz( $fuz ) : void {
    self::$fuz = $fuz;
  }

Foo::getFuz( Config::FUZ );
$foo = new Foo;

so erspart man sich bei Instanziierung gleichzeitig die Konfigurierung der Instanz. Jedoch muss die Konfigurierung statt finden sonst funktioniert das nicht 😕.

[pl]

Warum der Umweg über eine statische Methode? Denk' an Rotkäppchen! Little Red Riding Hood Pattern 😉

Also ich würde eine Konfiguration bzw. eine Referenz auf diese ohne Umschweife direkt in den Konstruktor geben.

Freundschaft 😉

[MB]

Ok, ich danke Dir für diesen Rat! vlg MB

[pl]

Was Routing betrifft: Unterscheide einen statischen Teil und einen Dynamischen (Parameter). Der Name des Controllers (Klassenbindung) sollte nicht im URL sichtbar sein (obwohl das einige Frameworks machen). Konfiguriere die Klassenbindung vielmehr im statischen Teil der Routingtable und lege eine Referenz auf die Routingtable als Property in den Instanz derjenigen Klasse die den Request entgegennimmt.

Freundschaft 😉

[dedlfix]

Tach!

Der Name des Controllers (Klassenbindung) sollte nicht im URL sichtbar sein (obwohl das einige Frameworks machen).

Wie lautet dazu die Begründung?

dedlfix.

[TS]

Hello,

Der Name des Controllers (Klassenbindung) sollte nicht im URL sichtbar sein (obwohl das einige Frameworks machen).

Wie lautet dazu die Begründung?

Ich möchte erst einmal nach einem Positivbeispiel und einem Negativbeispiel fragen, bevor ich mich eventuell der dauernden Mobbingaktion gegen Rolf anschließe.

Also Rolf: Bitte sei so arbeitsam und zeige uns ein (deiner Meinung nach) positives und ein negatives Beispiel und begründe beide.

Liebe Grüße
Tom S.

[pl]

Klassennamen in URL zu kodieren führt dazu, dass Routing nicht sauber vom Code entkoppelt ist. Eine Änderung des Klassennamen hätte eine Änderung des URL zur Folge. Content-Negotiation über die Klasse regeln zu wollen ist außerdem auch nicht möglich.

Außerdem wird die Routingtable unnötig groß, wenn dynamische Anteile quasi statisch gemacht werden.

Freundschaft 😉

[TS]

Hello,

[...]

Das versteht doch kein Schwein. Und Menschen auch nur dann, wenn sie schon wissen, worum es geht!

BITTEEEE: vernünftige Beispiele und dann müssen auch die Kritiker zugeben, dass sie Dich nur mobben wollten!

Aber so hingerotzte Wahrheiten führen eben immer zu Gegenwehr, auch wenn die eigentlich unberichtigt ist.

Liebe Grüße
Tom S.

[pl]

Beispiele findest Du in der Dokumentation zu meinem Framework die sehr umfangreich ist. Vergleiche mit anderen Frameworks musst Du jedoch selber machen.

Freundschaft 😉

PS: Die Klassnbindung findest Du als Kommentar im Quelltext einer jeden Seite.

[Matthias Apsel]

Hallo pl,

Beispiele findest Du in der Dokumentation zu meinem Framework die sehr umfangreich ist.

Das ist höchstens ein Flyer, aber keine Dokumentation.

Bis demnächst
Matthias

[pl]

Sorry diese Bemerkung finde ich nicht gerade nett. Weil die Seite die Du geringschätzig als Flyer bezeichnest sowohl den Index also auch die restlichen Dokumente verlinkt.

Das ist höchstens ein Flyer, aber keine Dokumentation.

Ist eher arrogant.

Ein bischen mehr Zeit musst Du schon investieren wenn Du Dich da einlesen willst.

[Matthias Apsel]

Hallo pl,

Sorry diese Bemerkung finde ich nicht gerade nett. Weil die Seite die Du geringschätzig als Flyer bezeichnest sowohl den Index also auch die restlichen Dokumente verlinkt.

Stimmt. Das Inhaltsverzeichnis habe ich nicht wahrgenommen. Tut mir leid.

Bis demnächst
Matthias

[pl]

Und eine Suchfunktion gibt es schließlich auch. Und was eine statische Route ist @TS erklärt sich eigentlich von selbst. Dynamisch hingegen sind Parameter die zu einer statischen Route hinzukommen.

Parameter, das sind Komponenten die über die Schnittstelle CGI/1.1 vom Webserver adressiebar gemacht wurden; sie sind in einem abstrakten Datentyp mit dem Namen Serverumgebung für den nachgelagerten Prozess zugänglich. Des Weiteren definiert CGI/1.1 STDIN und STDOUT als Common Gateway.

Parameter kann es unendlich viele geben, z.b. QUERY_STRING's die an einen statischen URL angehängt werden können. Es ist technisch nicht möglich, unendlich viele Routen die sich daraus ergeben, in einer Tabelle im Hauptspeicher vorzuhalten. Schon von daher ergibt sich objektiv eine Notwendigkeit der Trennung, die Anzahl statischer Routen ist endlich.

Praktisch sollte zu einem unerwarteten Parameter like /index.html?edit=123&admin=hugo auch eine Fehlermeldung generiert werden die sich auf den statischen Anteil /index.html bezieht anstatt sowas mit einem generellen Status 404 Not Found zu beantworten.

Frameworks wie z.B. .net routen über eine Mustererkennung was zum Ziel hat, aus einer unendlichen Anzahl möglicher Routen eine endliche Anzahl zu machen die sich im Code wiederfindet. Eine saubere Trennung ist das jedoch nicht.

Und schließlich Content-Negotiation: /index.html liefert verschiedene Inhalte. Also ein URL, verschiedene Inhalte. Das kann man über die Klassenbindung regeln dass der URL bleibt aber wenn die Klassenbindung im URL kodiert ist, hast Du eben verschiedene URLs.

Das sind sozusagen Überlegungen erster Ordnung, d.h. beim Code sind wir da noch lange nicht.

MfG

[Rolf B]

Frameworks wie z.B. .net routen über eine Mustererkennung was zum Ziel hat, aus einer unendlichen Anzahl möglicher Routen eine endliche Anzahl zu machen die sich im Code wiederfindet. Eine saubere Trennung ist das jedoch nicht.

Die Idee in ASP.NET MVC war "Convention before Configuration", d.h. MS hat es als Feature verstanden, dass die URL direkt auf Controller mappt, nicht als besondere Mühe. Man muss das aber nicht tun. Ich kann auch ein Muster wie "dings.html" „erkennen“ und dem hart den Controller "Foo" mit der Methode "Bar" zuordnen. Und ich kann die Routing-Table im Programm codieren, oder eine Funktion schreiben, die sie aus einer Datei einliest. Dynamisch ändern kann ich sie allerdings nicht, so weit ich weiß, dafür muss ich das Web neu starten.

Und schließlich Content-Negotiation: /index.html liefert verschiedene Inhalte. Also ein URL, verschiedene Inhalte. Das kann man über die Klassenbindung regeln dass der URL bleibt aber wenn die Klassenbindung im URL kodiert ist, hast Du eben verschiedene URLs.

Der einzige Content, den deine index.html mir gerade aushandelt, ist ein HTTP 404 - wasn da kaputt?

In .net würde ich so vorgehen, dass ich der index.html in der Routingtable einen Main Controller (oder sonstwas) zuordne, darin die relevanten Kriterien für variablen Content überprüfe und dann den gewünschten View erzeuge. Welche konfigurativen Möglichkeiten MVC an dieser Stelle noch bietet, darin bin ich nicht ganz so firm. Aber wenn's drum geht, je nach Berechtigung Content anzubieten, ist man konfigurativ vermutlich eh am Ende.

Rolf

[dedlfix]

Tach!

Und schließlich Content-Negotiation: /index.html liefert verschiedene Inhalte. Also ein URL, verschiedene Inhalte. Das kann man über die Klassenbindung regeln dass der URL bleibt aber wenn die Klassenbindung im URL kodiert ist, hast Du eben verschiedene URLs.

Wenn man das nicht möchte, kann man in ASP.NET MVC zusätzlich zur Route mit der Konvention {controller}/{action}/{id} weitere Routen hinzufügen. Wenn bei gleicher URL auf unterschiedliche Controller geroutet werden sollen, dann kann man als URL-Muster auch mehrfach denselben festen Wert angeben und als Ziel verschiedene Controller/Actions angeben. Die Unterscheidung trifft man dann über einen Constraints-Parameter. Über den kann man Teile der URL anhand einer RegExp auswerten lassen oder eine selbst geschriebenen Klasse angeben, die den Request nach Strich und Faden auswerten kann, um zu entscheiden, ob die Route passt.

Ergibt Konvention und Konfiguration, ohne aus das jeweils andere verzichten zu müssen. Ich sehe weiterhin keinen Grund, auf Konvention zu verzichten, wenn diese es mir erspart, große Teile meiner Routen händisch konfigurieren zu müssen.

Beispiel gefällig?

            routes.MapRoute(
                name: "Test1",
                url: "foo/{test}",
                defaults: new { controller = "Home", action = "About" },
                constraints:new { test = "bla" }
            );

            routes.MapRoute(
                name: "Test2",
                url: "foo/{test}",
                defaults: new { controller = "Home", action = "Contact" },
                constraints: new { test = "fasel" }
            );

            routes.MapRoute(
                name: "Default",
                url: "{controller}/{action}/{id}",
                defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
            );

Der dritte Methodenaufruf erstellt die Route, die nach Konvention aus den URL-Parametern den Controller und die Action ableitet, mit Defaultwerten für nicht vorhandene Teile.

Die ersten beiden Methodenaufrufe generieren Routen nach dem Prinzip der Konfiguration, indem zu beliebigen URLs beliebige Controller/Actions konfiguriert werden können. In dem Test-Projekt gibt es nur einen Controller mit drei Actions, deswegen ist das hier jedesmal derselbe Controller. Das Beispiel soll zeigen, dass man mit derselben URL auch zu unterschiedlichen Zielen routen kann. Das Unterscheidungskriterium ist hier der Einfachheit halber der zweite Teil der URL, weil ich dafür einfach ein RegExp-Muster in den Contraints angeben kann. Um wirklich dieselbe URL zu haben, müsste ich erst eine Klasse schreiben, die IRouteConstraint implementiert. Die kann dann auch andere Teile des Requests abseits der URL auswerten.

In .net würde ich so vorgehen, dass ich der index.html in der Routingtable einen Main Controller (oder sonstwas) zuordne, darin die relevanten Kriterien für variablen Content überprüfe und dann den gewünschten View erzeuge.

Ja, wenn das Auszuführende immer dasselbe oder größtenteils ähnlich ist, kann das derselbe Controller erledigen. Aber der ASP.NET-MVC-Router gibt mir die Flexibilität, auch unterschiedliche Controller unter derselben URL anzusprechen, wenn deutlich unterschiedliche Aufgagen zu erledigen sind. Wobei ich mir dann aber die Frage stelle, warum unter derselben URL grundverschiedene Dinge abgehandelt werden sollen, die eigene Controller erfordern.

Welche konfigurativen Möglichkeiten MVC an dieser Stelle noch bietet, darin bin ich nicht ganz so firm. Aber wenn's drum geht, je nach Berechtigung Content anzubieten, ist man konfigurativ vermutlich eh am Ende.

Nun, auch das kann ASP.NET MVC mit Konfiguration. Man schmückt Actions oder einen ganzen Controller mit einem Authorize-Attribut und gibt da an, welche Rollen zugreifen dürfen. Das ist die einfache Variante, die man beliebig veredeln kann. Somit hat man den Zugang am Controller konfiguriert, ohne den Code der Actions selbst um Prüfungen zu erweitern. Aber auch innerhalb der Actions kann man das tun, wenn man das unbedingt möchte.

dedlfix.

[pl]

Der einzige Content, den deine index.html mir gerade aushandelt, ist ein HTTP 404 - wasn da kaputt?

Nüscht kaputt. Die /index.html ist gar nicht konfiguriert, da gibts auch keine Route. Ich werd'se mal nachtragen. Freundschaft 😉

[pl]

In .net würde ich so vorgehen, dass ich der index.html in der Routingtable einen Main Controller (oder sonstwas) zuordne, darin die relevanten Kriterien für variablen Content überprüfe und dann den gewünschten View erzeuge. Welche konfigurativen Möglichkeiten MVC an dieser Stelle noch bietet, darin bin ich nicht ganz so firm.

Ich verstehe unter MVC eine Klasse für alles zusammen und eine statische Bindung an einen URL like /path/foo.html. Statisch heißt, dass auch die Route zu /path/foo.html?x=y statisch und über den Hauptspeicher im wahlfreien Zugriff ist und sich auch bei Parametern im Request nicht ändert.

Kommen Parameter (Benutzeraktionen) ins Spiel, z.b. eine von GET abweichende Requestmethode, bestimmte Requestheader und weitere, sich aus dem gesendeteten Enctype ergebende Parameter, ändert das höchstens das View was die Response ist. Alles Andere, die Klassenbindung und die Klasse selbst bleiben unverändert.

.net jedoch bildet verschiedene Aktionen die zu einem Modell gehören sowohl über verschiedene Path-Anteile eines URL als auch über unterschiedliche Controller Klassen ab. Das hat natürlich einige Konsequenzen die sich allesamt nicht gerade positiv in der Entwicklung auswirken und daraus bestimmte Empfehlungen abzuleiten ist durchaus legitim.

Freundschaft 😉

[dedlfix]

Tach!

BITTEEEE: vernünftige Beispiele und dann müssen auch die Kritiker zugeben, dass sie Dich nur mobben wollten!

Ich bitte dich, diese Unterstellungen zu unterlassen. Ich kritisiere seine Aussagen, ja, aber ich habe nicht die Absicht, ihn zu mobben. Selbst dann nicht, wenn er mir Beleidigungen an den Kopf wirft. Ich bin mir auch bewusst, dass Absicht und Wirkung unterschiedlich ausfallen können.

Das versteht doch kein Schwein. Und Menschen auch nur dann, wenn sie schon wissen, worum es geht!

Genau das ist ein wesentlicher Punkt, der mich zu meinen Antworten verleitet. Ich verstehe oftmals nur mit großen Mühen, was er meint, besonders wenn die Begrifflichkeiten nicht mit der allgmein üblichen Bedeutung verwendet werden.

Aber so hingerotzte Wahrheiten führen eben immer zu Gegenwehr, auch wenn die eigentlich unberichtigt ist.

Wenn ich irgendwo unberechtigte Nachfragen stelle, dann bitte ich darum, mich an Ort und Stelle darauf hinzuweisen. Ich kann im Nachhinein pauschale Beurteilungen nicht zu konkreten Begebenheiten zuordnen. Es fällt mir dann schwer, die genauen Kritikpunkte zu erkennen. Ansonsten kann ich nur generell aufhören, Dinge anzusprechen, zu denen ich eine andere Meinung habe, oder den Vorwurf als nicht nachvollziehbar zur Seite legen.

dedlfix.

[TS]

Hello,

[...]

ach!

Dann streitet Euch doch alleine weiter.

Ich mach dann mal wieder eine Pause im Forum und komme aktiv wieder, wenn sich mein Eindruck bezüglich Zusammenarbeit verbessert hat.

Liebe Grüße
Tom S.

[pl]

Weniger Abhängigkeiten.

[dedlfix]

Tach!

Weniger Abhängigkeiten.

Es besteht immer eine Abhängigkeit zwischen einer URL und dem aufzurufen Controller.

Es kommt darauf an, wie der Router gestaltet ist. Es gibt da das Prinzip Convention over Configuration. Da sorgt eine Festlegung dafür, dass man weniger Konfigurationsaufwand hat. Ein Beispiel einer Festlegung wäre, dass URLs der Form /a/b/c zum Controller a und dessen Action b mit dem Parameter c geleitet werden. Man schreibt seine Controller und Actions in der Form, wie die URLs aussehen sollen und spart sich damit weitere Arbeit. Das heißt jedoch nicht, dass man auf dieses Schema festgenagelt ist. Wenn der Router gut implementiert ist, ist die genannte Konvention nur der Default-Wert und man kann beliebige weitere Konfigurationen hinzufügen, die ganz individuell bestimmte URLs zu bestimmten Zielen leiten. Ich sehe diese Empfehlung als unbegründet an, da man auch sehr gut die Vorteile beider Vorgehensweisen (Konvention und Konfiguration) kombinieren kann.

dedlfix.

[TS]

Hello,

Es besteht immer eine Abhängigkeit zwischen einer URL und dem aufzurufen Controller.

Di kann man aber durch indirekten Aufruf entkoppeln!
Diese Technik liegt bereits dem popligsten Assembler-Code zugrunde!

Liebe Grüße
Tom S.

[dedlfix]

Tach!

Es besteht immer eine Abhängigkeit zwischen einer URL und dem aufzurufen Controller.

Di kann man aber durch indirekten Aufruf entkoppeln!

Nein, kann man nicht. Eine bestimmte URL muss immer vom selben Ziel bearbeitet werden (jedenfalls, wenn man ein deterministisches System betreiben möchte). Man kann nur die Art ändern, wie diese Abhängigkeit aufgelöst wird. Per Konvention (alle nach Schema F) oder per Konfiguration (jeder einzeln). Oder man mischt beide Vorgehensweisen.

Vielleicht meinst du ja auch etwas anderes, aber hilft mir eine solche Anfügung auch nicht beim Verständnis:

Diese Technik liegt bereits dem popligsten Assembler-Code zugrunde!

dedlfix.

[dedlfix]

Tach!

Es besteht immer eine Abhängigkeit zwischen einer URL und dem aufzurufen Controller.

Di kann man aber durch indirekten Aufruf entkoppeln!

Nein, kann man nicht. Eine bestimmte URL muss immer vom selben Ziel bearbeitet werden (jedenfalls, wenn man ein deterministisches System betreiben möchte). Man kann nur die Art ändern, wie diese Abhängigkeit aufgelöst wird. Per Konvention (alle nach Schema F) oder per Konfiguration (jeder einzeln). Oder man mischt beide Vorgehensweisen.

Nachtrag: Die Wortwahl URL ist, wenn man es genau nimmt, zu sehr einschränkend. Genauer gesagt muss man die Gesamtheit des Requests berücksichtigen. Dazu gehört die HTTP-Methode (oder Verb) und auch die Daten, die man aus den Headerzeilen gewinnen kann, und auch die im Body. Am Prinzip ändert das aber nichts, der Request muss einem Ziel zugeordnet sein. Ob diese Auflösung per Konvention oder Konfiguration oder mit einen Algorithmus erfolgt, ändert nichts daran, dass diese Zuordnung existiert und vom Router herausgefunden werden muss.

dedlfix.

[TS]

Hello,

Die kann man aber durch indirekten Aufruf entkoppeln!

Nein, kann man nicht. Eine bestimmte URL muss immer vom selben Ziel bearbeitet werden [...]

Da hat der Dedlfix aber die Rechnung ohne die diversen Proxies und deren Betreiber gemacht!

Ganz frech die Zunge raussteck! ;-P

Liebe Grüße
Tom S.

[pl]

Es besteht immer eine Abhängigkeit zwischen einer URL und dem aufzurufen Controller.

Vollkommen richtig, aber deswegen muss man sie nicht im URL kodieren, weil eine Änderung der Klasse zwangsläufig eine Änderung des URL nach sich zieht.

Freundschaft 😉

[dedlfix]

Tach!

Es besteht immer eine Abhängigkeit zwischen einer URL und dem aufzurufen Controller.

Vollkommen richtig, aber deswegen muss man sie nicht im URL kodieren, weil eine Änderung der Klasse zwangsläufig eine Änderung des URL nach sich zieht.

Wenn man gut plant, hat man wenig Bedarf Namen zu ändern. Aber selbst wenn das notwendig ist, kann man bei guten Router-Implementationen einen Konfigurationswert zur Defaultregel und den eventuellen anderen Regel hinzufügen, um diesen Fall abzufangen, falls wirklich URL und Controller unterschiedlich benannt bleiben sollen.

dedlfix.

[dedlfix]

Tach!

ich möchte wissen, ob man die Klasse Foo, aus der eine Instanz erzeug wird (z.B. $foo = new Foo( $fuz )), vorab mit statischen Methoden Foo::bar( $baz ) dieser Klasse Foo konfigurieren soll, bevor die Klasse Foo instanziiert wird. Man erspare sich einen zweiten Parameter bei der Instanziierung von Foo (z.B. $foo = new Foo( $fuz, $baz )).

Wenn du erst einen Konfigurationsschritt ausführen muss, um die Instanzen korrekt erzeugen zu können, dass ist das kein gutes Design. Du musst nämlich dann von diesem notwendigen Schritt wissen. Und er darf in keinem Fall vergessen werden, egal welchen Weg der Code nimmt. Du wirst den Schritt dann in eine gemeinsame Initialisierungsroutine einfügen wollen. Und er wird jedes Mal ausgeführt, auch wenn du gar keine Instanzen der Klasse brauchst. Folge ist auch, dass der Autoloader die Klasse umsonst laden muss. Wenn der Parameter stattdessen unverzichtbarer Bestandteil beim Instantiieren ist, kann er nicht vergessen werden und auch die anderen genannten Nachteile fallen weg. Das bisschen eingesparte Mehrarbeit bei einmaliger Initialisierung ist die Risiken und die Nachteile nicht wert.

dedlfix.

[MB]

moin dedlfix,

Wenn du erst einen Konfigurationsschritt ausführen muss, um die Instanzen korrekt erzeugen zu können, dass ist das kein gutes Design.

sehe ich exakt genauso!

Das bisschen eingesparte Mehrarbeit bei einmaliger Initialisierung ist die Risiken und die Nachteile nicht wert.

Ok sehe ich ein. Ich frage ist mir bei der URLRouter Klasse ensprungen. Der URLRouter muss die standart werden language, route, controller, action, params und Pfad dert er auser acht lassen soll, kennen. Wenn nämlich ein URL-String übergeben wird muss er default werde wissen in die er routen soll wenn keine wweiteren oder unzulässige angaben da sind: Bespiel: http::/www.myhomepage.de/mysection/de/default/home/index/welcom, wenn da weniger steht sollte der URLRouter die Pfade ergänzen oder umleiten können. Meine Denke. Wie siehst du das aus professioneller sichtweise?

vlg MB

[dedlfix]

Tach!

Ich frage ist mir bei der URLRouter Klasse ensprungen.

Von deinem Router wird üblicherweise nur eine einzige Instanz wärend des Requests benötigt. Da lohnt es sich gleich gar nicht, noch einen weiteren Schritt zum Initialisieren auszuführen.

dedlfix.

[MB]

Ich frage ist mir bei der URLRouter Klasse ensprungen.

Von deinem Router wird üblicherweise nur eine einzige Instanz wärend des Requests benötigt. Da lohnt es sich gleich gar nicht, noch einen weiteren Schritt zum Initialisieren auszuführen.

jetzt verstehe ich dich gernicht mehr. Was meinst du? welch Instanz, die was tut, mit welchen funktionsparametern, wärend des Requensts? Sorry, aber bin total perplex.

[dedlfix]

Tach!

Von deinem Router wird üblicherweise nur eine einzige Instanz wärend des Requests benötigt. Da lohnt es sich gleich gar nicht, noch einen weiteren Schritt zum Initialisieren auszuführen.

jetzt verstehe ich dich gernicht mehr. Was meinst du? welch Instanz, die was tut, mit welchen funktionsparametern, wärend des Requensts? Sorry, aber bin total perplex.

Wie oft verwendest du den Router im Verlauf der Abarbeitung eines Requests? Also, ein Client schickt deinem Webserver einen Request, woraufhin ein PHP-Script von dir gestartet wird. Von da an bis die Response vollständig erstellt wurde, wie oft brauchst du eine Instanz der Router-Klasse?

Die Antwort wird wohl 1 sein. Was ist dann einfacher?

Router::init($foo);
$router = new Router($bar);

oder

$router = new Router($foo, $bar);

Nicht komplizierer als nötig machen, besonders wenn die vermeintliche Ersparnis zu Mehraufwand führt.

dedlfix.

[MB]

ah ok jetzt bin ich wieder im Bilde. Den genau das war meine Frage:

so ...

Router::init($foo);
$router = new Router($bar);

... oder so ...

$router = new Router($foo, $bar);

Ich weis es nicht welchesder beiden besser ist.

Nicht komplizierer als nötig machen, besonders wenn die vermeintliche Ersparnis zu Mehraufwand führt.

Deswegen meine Frage. Wo liegt die Gründe für einer der beiden Vergehenweisen?

vlg MB

[dedlfix]

Tach!

Wo liegt die Gründe für einer der beiden Vergehenweisen?

Der Einzeiler ist in dem Fall der einmaligen Verwendung natürlich einfacher zu notieren. Zudem fällt weg, dass du für die andere Variante neben dem Konstruktor noch die statische Funktion erstellen musst.

dedlfix.

[MB]

Joa, das hat ja auch pl bestätigt. Danke dafür!