Ankündigung

Einklappen
Keine Ankündigung bisher.

PHP-Klasse für nationale/regionale Feiertage mit SQLite-DB als Konfiguration

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • PHP-Klasse für nationale/regionale Feiertage mit SQLite-DB als Konfiguration

    Ich möchte hier mein Konzept für nationale und regionale Feiertage vorstellen und diskutieren.
    Es gibt da für PHP schon eine Menge an Lösungen, z.B.

    yasumi
    Niirrty.Holiday
    holiday-calendar


    Eine weitere Klasse mach nur Sinn, wenn diese sich von den vorhandenen durch bestimmte Vorteile abhebt.
    Die sind:
    • Die Definition eines Feiertages soll zu 99% mit einen Eintrag in die SQLite-Datenbank erfolgen. Um soche Einträge vorzunehmen sind mehrere kostenfreie Tools verfügbar, die eine bequeme Administration ermöglichen. Für viele Fälle ist ein Anfassen/Erweitern des PHP-Codes nicht notwendig.
    • Das Regionen-Konzept ermöglicht die Definition von Feiertagen welche nur in bestimmten Gebieten gelten.
    • Es können zeitliche Bedingungen für die Feiertagsdefinition vergeben werden, z.B. nur für ein bestimmtes Jahr oder ein Bereich.
    • Es können Namen in allen Sprachen und auch unterschiedliche Namen je nach Land und Region vergeben werden.
    • Ein leistungsfähiger Datums-Formel-Parser ermöglicht die Berechnung z.B.von beweglichen Feiertagen.
    Das Regionen-Konzept hat eine max. 4 stufige Kennung aus

    Ländercode-[[[Subnationaler-Code]-Subregion1]-Subregion2]

    mit Trenner Minus - als Basis. Beispiele: DE, NL, DE-BY, DE-BY-SCH-A
    Feiertage mit der Region-Kennung DE gelten für ganz Deutschland ohne Ausnahme und mit der Kennung DE-BY für Bayern. Die Vergabe der Kennungen obliegt den Ersteller der DB-Einträge.
    Es wird jedoch empfohlen sich möglichst weit an die ISO 3361 anzulehnen. Die Kennung DE-BY-SCHW-A steht für Deutschland-Bayern-Schwaben-Augsburg(Stadt). Wird nun eine Feiertagsliste mit der Regionalkennung DE-BY-SCHW-A angefordert werden automatisch alle Regionen mit DE, DE-BY und DE-BY-SCHW mit einbezogen. Dieses Regionen-Konzept vereinacht auch die Administration der Datenbank. So ist Neujahr in vielen Ländern ein gesetzlicher Feiertag. Unter Region ist dann ein Eintrag wie z.B. DE,CH,AT,NL zu finden.

    Für jeden Feiertag können nach belieben viele Spracheinträge vorhanden sein. Eine Unterscheidung nach Sprachgebieten/Dialekten kann auch erfolgen (de-DE, de-CH,..). So können unterschiedliche Namen für die gleichen Feiertage vergeben werden, z.B. für de-DE 'Christi Himmelfahrt' und für de-CH 'Auffahrt'.

    Für Feiertage mit fixen Datum steht die Felder month und date zur Verfügung. Ausnahmen für bestimmte Jahre können durch Einträge in den Feldern year und notyear erreicht werden. Diese Einträge können auch als Komma getrennte Liste und Bereiche von - bis erfolgen.

    Der Eintrag unter special der von einen Datums-Formel-Parser ausgewertet wird rundet die Sache ab. Spezielle Platzhalter wie {{easter}} in Verbindung mit der Interpretation von relativen Formaten und Verkettungen (Chain) bringen eine extrem hohe Flexibilität. Dies lässt sich wohl am Besten durch einige Beispiele für DB-Einträge demonstrieren:
    .
    comment year notyear month day special region
    Christi Himmelfahrt {{easter}}|+39 Days DE,CH,AT,NL
    Reformationstag 2017 10 31 DE-BW,DE-BB,DE-MV,DE-SN,DE-ST,DE-TH
    Reformationstag 2017 2017 10 31 DE
    Buß und Bettag 11 23 last Wed DE-SN
    Genfer Bettag first sunday of september {{year}}|next thursday CH-GE
    .
    In einigen Ländern gibt es Ausnahmen, die vom Wochentag und/oder anderen Feiertagen abhängen. Dafür eine allgeimgültige Vorschrift zu finden ist oft
    mit einen erheblichen Zeitaufwand verbunden. Eine Liste für einen bestimmten Feiertag für mehrere Jahre findet sich dagegen schnell.
    Um solche Listen in die Datenbank einpflegen zu können ist ein spezieller Selector-Platzhalter verfügbar.
    {{YYYY:Ausdr1,Ausdr2,..}}
    YYYY ist das Startjahr. Entsprechend dem aktuellen Jahr wird der Ausdruck gewählt und ersetzt. Beispiel:
    {{2018:4/19,5/9,4/29,4/15,5/5,4/26,5/14,5/1,4/22,5/12,5/2}}
    Für das Jahr 2019 wird dann "5/9" ausgewählt was in Verbindung mit dem Jahr dann "2019-05-09" als Datum liefert.

    So, ich denke, alle bisherigen Anregungen aus Beiträgen im Forum berücksichtigt zu haben. Es ist jedoch nicht ausgeschlossen, das für bestimmte Regionen/Kalender Erweiterungen wünschenswert werden. Dies kann dann durch selbst gewählte Platzhalter {{myspecial}} in Verbindung mit einer gleichnamigen Methode in einer Erweiterungsklasse realisiert werden. Für die ersten Test's war jedoch bisher immer nur ein neuer Datenbankeintrag notwendig.

    Hinweis:
    Die Datenbank ist entgegen gängiger Praxis zu Gunsten einer einfachen Administration nicht normalisiert. Der Performanceverlust dürfte sich durch den für Datenbanken sehr kleinen Umfang an Datensätzen in Grenzen halten.

    Freue mich wie immer auf Feedback sein es weitere Hinweise, Anregungen, Bedenken oder Kritik.

    LG jspit

  • #2
    1. Warum eine sqllite-Datenbank anstelle von einfachen Config-Files im Textformat?
    Wenn's dir um einfachere Abfrage oder Performance geht könntest du die sqllite-db ja immer noch aus den Config-Files erstellen (als Cache quasi).


    2. Die Aufteilung in year/noyear, month, day und special müsste auch nicht sein finde ich.
    Das könnte alles über 1 Feld gemacht werden.
    Ein Datum im Format YYYY-MM-DD oder MM-DD lässt sich einfach erkennen.


    2.1 Am wenigsten gefällt mir das notyear.
    Das könnte man auch über die schon verwendete Pipe Syntax machen
    Code:
    Reformationstag --> 10-31|except 2017
    Vllt.stört mich auch einfach nur die Bezeichnung. except_year klingt irgendwie mehr nach dem, was es ist.


    2.2 Da man das Jahr nicht so oft braucht, lässt man es vllt. gleich ganz weg und macht das auch über die Pipe Syntax
    Code:
    Reformationstag      --> 10-31|except 2017
    Reformationstag 2017 --> 10-31|only 2017
    2.3
    evtl. auch mit erweiterter Syntax:
    Code:
    nur alle 5 Jahre --> 07-17|year 2000,2005,2010,2015
    von-bis          --> 05-20|years 2000..2020
    Reformationstag  --> 10-31|years 1990..|except 2017
    Anmerkungen:
    - only, year und years sind äquivalent
    - Bei Angabe einer Range (mit ..) kann man Start und Ende weglassen.



    Grüße.

    Kommentar


    • #3
      Zitat von php1704 Beitrag anzeigen
      1. Warum eine sqllite-Datenbank anstelle von einfachen Config-Files im Textformat?
      Wenn's dir um einfachere Abfrage oder Performance geht könntest du die sqllite-db ja immer noch aus den Config-Files erstellen (als Cache quasi).
      Das Hantieren mit mehreren Config-Files egal ob als JSON, CSV oder als PHP-Skript ist nun genau nicht nach meinem Geschmack.
      In der SQLite Datenbank habe ich 2 Tabellen, eine für die Feiertage und eine für die Namen für die diversen Sprachen, die in einer 1:n-Beziehung stehen. Das als Textdatei(n) abzubilden da hab ich erstmal keine Idee dafür. Bin auch der Meinung das Textdateien weit mehr fehleranfällig sind und weniger Übersicht bieten. Das gilt insbesondere für Einsteiger und das bekommt man hier fast täglich im Forum gezeigt (Zeichensatzproblematik, fehlerhaftes JSON usw.)
      Wer mit Textdateien besser zurecht kommt, kann da ja die Ex- und Importfunktionen des Datenbanktools (Ich nutze da DB Browser http://sqlitebrowser.org/) bemühen.
      Und das Schöne an SQLite ist ja, das ist alles in einer einzigen Datei holiday.sqlite.

      Zitat von php1704 Beitrag anzeigen
      2. Die Aufteilung in year/noyear, month, day und special müsste auch nicht sein finde ich.
      Das könnte alles über 1 Feld gemacht werden.
      Ein Datum im Format YYYY-MM-DD oder MM-DD lässt sich einfach erkennen.
      Klar, ist machbar. Ich sehe hier aber nicht den Vorteil durch die Einsparung von ein paar Datenbankfeldern. Die Masse der Feiertage hat ein fixes Datum und benötigt kein Special-Eintrag. Finde das so übersichlicher und weniger fehleranfällig.

      Zitat von php1704 Beitrag anzeigen
      2.1 Am wenigsten gefällt mir das notyear.
      Das könnte man auch über die schon verwendete Pipe Syntax machen
      Code:
      Reformationstag --> 10-31|except 2017
      Vllt.stört mich auch einfach nur die Bezeichnung. except_year klingt irgendwie mehr nach dem, was es ist.
      Hatte anfangs die Variante mit !2017 im year-Feld. Das fand ich unübersichtlich und zudem war es schlechter umsetzbar. Da hab ich das Feld noyear hinzugenommen. Der Bezeichner ist zugegeben nicht sehr aussagekräftig. Habe dein Vorschlag except_year übernommen.

      Zitat von php1704 Beitrag anzeigen

      2.2 Da man das Jahr nicht so oft braucht, lässt man es vllt. gleich ganz weg und macht das auch über die Pipe Syntax
      Code:
      Reformationstag --> 10-31|except 2017
      Reformationstag 2017 --> 10-31|only 2017
      2.3
      evtl. auch mit erweiterter Syntax:
      Code:
      nur alle 5 Jahre --> 07-17|year 2000,2005,2010,2015
      von-bis --> 05-20|years 2000..2020
      Reformationstag --> 10-31|years 1990..|except 2017
      Anmerkungen:
      - only, year und years sind äquivalent
      - Bei Angabe einer Range (mit ..) kann man Start und Ende weglassen.
      Das geht mir dann schon zu sehr in Richtung einer eigenen speziellen Sprache, die der Nutzer dann erstmal begreifen muss. Habe da schon Bauchschmerzen bei meinen Selector-Platzhalter a.la {{2018:4/19,5/9, ..}}. Das Problem ist ja hier weniger die Auswertung eines korrekten Ausdrucks als die Fehlerbehandlung bei Syntaxfehlern. Da bin ich noch bei der Findung was ich in einen solchen Fall mache. Würde man ein normales fixes Datum mit in die Pipe Syntax stecken wird das auch teuer, da bei check ob ein bestimmtes Datum ein Feiertag ist für alle Zeilen der Tabelle bis zum Treffer das special-Feld geparst werden muss.
      Bei dem aktuellen Stand der Realisierung wird zuerst geprüft ob das special-Feld belegt ist. Wenn ja, dann wird nach den {{ }} gesucht und diese ersetzt, bevor der Pipe gesplittet wird und dann einfach stückweise DateTime::modify hingeworfen wird. Das ganze geht noch recht fix (weinige Millisekunden für eine Jahresliste mit Datum + Namen).

      Schonmal schönes WE
      jspit

      Kommentar


      • #4
        Hi,
        eine Erstversion der Klasse ist fertig. Die Klasse selbst hat nur wenige effiziente Methoden, besteht nur aus einer Datei und ist unter den PHP-Versionen von 5.4 - 7.2 lauffähig. Eine kleine SQLite-Datenbank wird mitgelefert welche Beispiele enthält und als Basis für eigene Definitionen von Feiertagen genutzt werden kann. Es ist nicht geplant, diese Datenbank für alle möglichen Regionen der Welt zu erweitern.
        Einige Test's + Demos werden demnächst noch zugefügt.

        Das oben vorgestellte Pipe-Konzept wurde durch Hinzunahme von Bedingungen erweitert. Eine Bedingung kann in Abhängigkeit von Wochentagen, festen Daten oder Schaltjahren erstellt werden. Diese Bedingung kann als Filter arbeiten oder eine Aktion bewirken. Dies wird besser durch Beispiele verständlich.
        So haben einige Länder die schöne Regel, dass wenn ein Feiertag auf einen Sonntag/Wochenende fällt, dann der folgende Montag als zusätzlicher freier Tag zur Verfügung steht. Diese Regel wird durch einen einfachen Datenbankeintrag umgesetzt:

        {{?D=Sat,Sun}}|next Monday

        Damit sind auch Berechnungen von Ersatzfeiertagen wie für Weihnachten des UK möglich, die dann je nach Konstellation am Montag oder Dienstag anfallen.
        Auch ein Verschieben von Feiertagen ist machbar:

        {{?D=Thu}}+1 Day

        Bei dieser Schreibweise wird wenn der Feiertag auf ein Donnerstag fällt dieser auf den Freitag verlegt.

        LG jspit

        Kommentar


        • #5
          Ich hoffe du bist offen für konstruktive Kritik. Es gibt ein paar Punkte welche mich vom Einsatz der Klasse abhalten würden bzw. was ich noch Verbessern würde:
          1. Die feste Abhängigkeit zu sqlite. Wenn mein ganzes Projekt auf z.B. MySQL basiert, werde ich hier gezwungen z.B. in meinem Docker Image auch den sqlite Treiber für PDO zu installieren. Ich würde mir da ein LoaderInterface wünschen, was mir erlaubt ein eigenen Loader für die Daten zu schreiben. Oder wenigsten, da du ja bereits PDO benutzt, die Möglichkeit einfach eine PDO Verbindung an den Constructor zu übergeben.
          2. Du hältst dich beim Klassen Namen nicht an den PSR Standard "Class names MUST be declared in StudlyCaps". Das mag erstmal kleinkariert wirken, wenn aber alles andere in deinen Projekten dem Standard folgt, fühlt es sich falsch an wenn nur eine Klasse anders ist.
          3. Deine Klasse befindet sich im globalen Namespace. Wenn jetzt irgendeine andere Library auch ohne Namespace eine Klasse holiday mitliefert, crasht die ganze Anwendung.
          4. Mir fehlt eine composer.json und Version-Tags auf GitHub. So müsste ich jetzt nur für die eine Klasse das Autoloading selber übernehmen/konfigurieren.

          Kommentar


          • #6
            4. definiere die Rückgabewerte sauber in phpdoc
            5. Exceptions
            -PHP bringt mit SPL feiner granulierte Exceptions mit: https://secure.php.net/manual/de/spl.exceptions.php
            -__CLASS__/__METHOD__ kannst du dir meiner Meinung nach sparen -> eine Exception beinhaltet immer einen Stacktrace
            -Die Fehlerbehandlung mit PDO ist Quark. Du hast den Exception Mode aktiviert, prüfst aber Rückgabewerte auf false (die so nie false werden könnne) und willst dann eigene Exceptions werfen oder false zurückgeben.

            Kommentar


            • #7
              Zitat von Zeichen32 Beitrag anzeigen
              Es gibt ein paar Punkte welche mich vom Einsatz der Klasse abhalten würden bzw. was ich noch Verbessern würde:
              Die feste Abhängigkeit zu sqlite. Wenn mein ganzes Projekt auf z.B. MySQL basiert, werde ich hier gezwungen z.B. in meinem Docker Image auch den sqlite Treiber für PDO zu installieren.
              Sehe ich nicht als Problem. PDO incl. SQLite (+MySQL)-Treiber sind heutzutage m.E. bei so gut wie jeder PHP-Installation mit an Bord. Zumindest habe ich in den letzten Jahren keine PHP-Installation gesehen wo kein SQLite-PDO-Treiber dabei war. Und bei SQLite gibt es ja auch nichts zu installieren wie zum Beispiel bei MySQL.
              PDO und SQLite laufen ja isoliert innerhalb der Klasse. Der Name (+Pfad) der Konfigurationsdatei werden per Konstruktor übergeben. Erstellt wird die Konfigurationsdateidatei mit einen der vielen Tools für SQLite.

              Zitat von Zeichen32 Beitrag anzeigen
              Ich würde mir da ein LoaderInterface wünschen, was mir erlaubt ein eigenen Loader für die Daten zu schreiben. Oder wenigsten, da du ja bereits PDO benutzt, die Möglichkeit einfach eine PDO Verbindung an den Constructor zu übergeben.
              Hintergrund dieses Wunsches ist mir unklar. Was ist einfacher als eine einzige Konfigurationsdatei zu laden? Welche Vorteile soll ein eigener Loader bringen und wie sieht der aus? Wo kommen diese Daten her?
              Welche Vorteile soll eine PDO-Verbindung bringen? Wenn daran gedacht wird die Konfigurationsdaten mit den Projektdaten zu mischen, das halte ich für die denkbar schlechteste Idee.

              Zitat von Zeichen32 Beitrag anzeigen
              [*]Du hältst dich beim Klassen Namen nicht an den PSR Standard "Class names MUST be declared in StudlyCaps". Das mag erstmal kleinkariert wirken, wenn aber alles andere in deinen Projekten dem Standard folgt, fühlt es sich falsch an wenn nur eine Klasse anders ist.

              Deine Klasse befindet sich im globalen Namespace. Wenn jetzt irgendeine andere Library auch ohne Namespace eine Klasse holiday mitliefert, crasht die ganze Anwendung.[*]Mir fehlt eine composer.json und Version-Tags auf GitHub. So müsste ich jetzt nur für die eine Klasse das Autoloading selber übernehmen/konfigurieren.
              Diese Punkte werde ich nochmal überdenken.

              Zitat von erc Beitrag anzeigen
              4. definiere die Rückgabewerte sauber in phpdoc
              5. Exceptions
              -PHP bringt mit SPL feiner granulierte Exceptions mit: https://secure.php.net/manual/de/spl.exceptions.php
              -__CLASS__/__METHOD__ kannst du dir meiner Meinung nach sparen -> eine Exception beinhaltet immer einen Stacktrace
              -Die Fehlerbehandlung mit PDO ist Quark. Du hast den Exception Mode aktiviert, prüfst aber Rückgabewerte auf false (die so nie false werden könnne) und willst dann eigene Exceptions werfen oder false zurückgeben.
              Gilt auch für diese Punkte. Insbesondere Punkt 5 betreff kann da noch nachgebessert werden.

              Danke für die Hinweise.

              LG jspit

              Kommentar


              • #8
                Einfach die Methoden, welche du zum holen der Daten benötigst in einen Adapter mit Interface auslagern, und schon kann jeder Anwender bei bedarf sein eigenen Loader für die Daten implementieren. Wo die Daten dann herkommen, ist und sollte deiner Klasse dann ja egal sein. Dein sqlite Adapter würde ich dann einfach standardmäßig mit der Klasse ausliefern.

                PHP-Code:
                interface LoaderInterface {
                public 
                getHolidayNameById($id$language);
                public function 
                getNames($nameFilter ""$language null$onlyCurrentRegion false);

                Kommentar


                • #9
                  Zitat von jspit Beitrag anzeigen
                  Sehe ich nicht als Problem. PDO incl. SQLite (+MySQL)-Treiber sind heutzutage m.E. bei so gut wie jeder PHP-Installation mit an Bord. Zumindest habe ich in den letzten Jahren keine PHP-Installation gesehen wo kein SQLite-PDO-Treiber dabei war. Und bei SQLite gibt es ja auch nichts zu installieren wie zum Beispiel bei MySQL. PDO und SQLite laufen ja isoliert innerhalb der Klasse. Der Name (+Pfad) der Konfigurationsdatei werden per Konstruktor übergeben. Erstellt wird die Konfigurationsdateidatei mit einen der vielen Tools für SQLite.
                  Damit brichst du zwei grundlegende Prinzipien: SRP und DIP. Viele Sackgassen lassen sich vermeiden indem man auf "new" verzichtet und Abhängigkeiten stattdessen über den Konstruktur bezieht.

                  Zitat von jspit Beitrag anzeigen
                  Hintergrund dieses Wunsches ist mir unklar. Was ist einfacher als eine einzige Konfigurationsdatei zu laden? Welche Vorteile soll ein eigener Loader bringen und wie sieht der aus? Wo kommen diese Daten her?
                  Welche Vorteile soll eine PDO-Verbindung bringen? Wenn daran gedacht wird die Konfigurationsdaten mit den Projektdaten zu mischen, das halte ich für die denkbar schlechteste Idee.
                  Was wenn ich SQLite gar nicht nutzen *will*? Wieso schreibt mir eine Klasse, die irgendwas mit Feiertagen macht, überhaupt vor wie ich mein Projekt konfigurieren und wo ich meine Daten speichern soll? Der Hinweis mit dem LoaderInterface geht da schon in eine sehr gute Richtung.
                  [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                  Kommentar


                  • #10
                    Diese Klasse schreibt dir nicht vor, wo du deine Daten speichern sollst. Die kannst du mit MySQL, Postgres oder sonst was speichern. Diese Holiday-Klasse gibt nur vor, in welcher Form sie ihre speziellen Konfigurationsdaten haben möchte. Diese Konfigurationsdatei hat einen für die Klasse zugeschnittenen Aufbau und sollte um Gotteswillen nicht noch für eigene Projektdaten benutzt werden. Es wird eine strikte Trennung zwischen eigenen Projektdaten und den Konfigurationsdaten für die Holiday-Klasse gefordert. Die Konfigurationsdaten der Klasse bestimmt allein die Leistungsfähigkeit der Klasse (also wie viele Länder/Regionen/Sprachen unterstützt werden).
                    Andere Konzepte wie z.B. yasumi haben für diese Daten spezielle interne Ordnerstrukturen mit einer Unzahl Dateien. Um die Leistungsfähigkeit der Klasse zu erweitern muß in diesen Strukturen gearbeitet werden. Aber genau dies ist ein Punkt der mir nicht gefällt.
                    yasumi unterstützt jedoch mit einem ProviderInterface und einem TranslationsInterface den Gedanken des Loaderinterfaces. Ich möchte meine Klasse jedoch möglichst flach und einfach halten. Wer also Ambitionen in Richtung LoaderInterface hat, sollte sich diese Klasse mal anschauen.

                    Kommentar


                    • #11
                      Bleibt weiterhin die Frage: was wenn ich SQLite gar nicht nutzen *will*? Als Library-Autor hast du zwei Möglichkeiten: entweder die potentiellen Nutzer haben halt Pech gehabt oder du bietest eine entsprechende Schnittstelle (LoaderInterface) mit einer Standard-Implementierung (SQLiteLoader). Wenn du der einzige Mensch bist der das Ding benutzt, ist das natürlich alles irrelevant.
                      [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                      Kommentar


                      • #12
                        Zitat von jspit Beitrag anzeigen
                        Ich möchte meine Klasse jedoch möglichst flach und einfach halten. Wer also Ambitionen in Richtung LoaderInterface hat, sollte sich diese Klasse mal anschauen.
                        Ein Interface macht ja die Klasse nicht wirklich komplexer. Der Aufwand ist minimal, dafür wird sie um ein vielfaches flexibler.

                        Kommentar


                        • #13
                          Zitat von lottikarotti Beitrag anzeigen
                          Bleibt weiterhin die Frage: was wenn ich SQLite gar nicht nutzen *will*?
                          Ja, wenn diese Suppe dir nicht schmeckt dann musst du dir eines der vielen anderen Gerichte auswählen welche SQLite nicht nutzen.
                          Diese Klasse macht sich nun mal einige der speziellen Eigenschaften von SQLite und deren Administrationstools zunutze. Und genau da sehe ich den Vorteil der Klasse.
                          Wären die Konfigrationsdaten in z.B. Textfiles untergebracht, wie es im Beitrag #2 vorgeschlagen wurde, und ich würde z.B. den Zugriff mit SplFileObject realisieren, würde wohl kaum einer auf die Idee kommen zu sagen er mag SplFileObject nicht und wohl auch nicht fordern die Instanz per Konstruktor zu übergeben.


                          Zitat von hellbringer Beitrag anzeigen
                          Ein Interface macht ja die Klasse nicht wirklich komplexer. Der Aufwand ist minimal, dafür wird sie um ein vielfaches flexibler.
                          Dabei bleibt es doch nicht. Ich sehe auch nicht, welcher Loader als Alternative zu SQLite da Sinn machen würde. Ich bin etwas davon abgerückt, Flexibilität für Fälle zu implementieren, die dann nie eintreten.

                          Kommentar


                          • #14
                            Zitat von jspit Beitrag anzeigen
                            Dabei bleibt es doch nicht. Ich sehe auch nicht, welcher Loader als Alternative zu SQLite da Sinn machen würde.
                            Das kann dir ja egal sein. Du hast deinen SQLite-Loader und fertig. Was andere daraus machen ist ihr Bier.

                            Kommentar


                            • #15
                              Da schreibt jemand ein Script für sich, stellt es der Allgemeinheit kostenlos zur Verfügung und muss nur Kritik einstecken.
                              Wenn es einem nicht gefällt, ein Fork draaus machen und abändern oder aber ignorieren und sich anderen Scripten zuwenden.

                              Ich denke man kann nur etwas verlangen wenn man auch dafür bezahlt.

                              Ist ein wenig wie wenn ich ein Auto geschenkt bekomme und dann noch meckere, dass der TÜV nächste Woche fällig ist.

                              Kommentar

                              Lädt...
                              X