Ankündigung

Einklappen
Keine Ankündigung bisher.

phpCraftBox

Einklappen

Neue Werbung 2019

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

  • phpCraftBox

    Das mit dem, das ist das das 1000ste neuerfunde Rad, würde ich gerne Überspringen.
    Es ist ein Hobbyprojekt von mir, das nun eine gewisse Größe erreicht hat.

    Was das System von anderen Unterscheidet:

    - Großer Verzichtung auf Abhängigkeiten von Drittambietern.
    - Schnelle und saubere Umsetzung von neuen Apps, Modulen etc. Durch Vorlagen / Standards.
    - Eigenes, (Natürlich PHPDoc kompatibles) Dolumentationssystem.
    - Sehr vielseitig einsetzbar: Ticketsystem, Shop, Intranet etc. pp. Ebend eine Bastel Box mit PHP.

    Das System bietet unter anderem;

    - OOP
    - DRY
    - KISS
    - DIC
    - etc. pp.
    - Eine Debugging Bar am unteren Seitenrand mit Zahlreichen Informationen. Query, Debug Dumps, Cache Zugriff, Datei Zugriff
    - Fehler werden intelligent abgefangen.
    - Cache über SQLite
    - Kein Routing System über die URL. Routen werden per Installation der Apps, Module etc. angelegt.

    Entwicklungsinformationen

    - Ein PHP Framework wird nicht genutzt, es ist vom Scratch erstellt.
    - phpstan wird durch Docker genutzt. Es wurden schon etliche Anpassungen durchgeführt. Im Entwickler App Bereich wurde eine App erstellt, welche die Json Ausgabe analysiert und als Tabelle darstellt. Ich musste einige Empfehlungen von phpstan wieder Rückgängig machen, da mein Server nur max. PHP 7.4 unterstützt.
    - Unit Test sind in Planung. Werden mit Hilfe der Development Tools und Docker umgesetzt.
    - Bug Reports & Feature Requests werden über ein externes Besprochen und dann über Issues abgearbeitet.
    - Entwickelt wird mit der Docker XAMP Umgebung Devilbox

    U.a. Was fehlt:

    - Mehr Dokumentation (wie immer).
    - Sprachanpassung, primär für die Menüs für Documentation, Config und Language.
    - Responsive Frontend Anpassung
    - Erweiterung auf Hybrid CMS
    - API Schnittpunkte
    - Altlasten Entfernung (Die meisten sollten gefunden sein)
    - Event Punkte
    - Weitete Applikationen

    URL:
    https://github.com/phpCraftBox/phpcraftbox

    Wer Interesse hat mitzumachen, einfach hier oder per PN melden.

  • #2
    Für meinen Geschmack zu viele statische Abhängigkeiten. Ich sehe da haufenweise Probleme vorprogrammiert. Mit DI hat das Ganze IMHO nix zu tun. Bei richtigem DI gibts keine statischen Abhängigkeiten, sondern die erforderlichen Objekte werden im Konstruktor übergeben. Diese Container-Klasse, so wie sie existiert, sollte meiner Meinung nach entsorgt werden, da sie ein Anti-Pattern ist.

    Und ohne Verwendung von Namespaces ist es bei so allgemeinen Klassennamen wie "Core", "Container", usw. ist es nur eine Frage der Zeit, bis es zu Namenskonflikten kommt.

    Kommentar


    • #3
      Zitat von hellbringer Beitrag anzeigen
      Für meinen Geschmack zu viele statische Abhängigkeiten. Ich sehe da haufenweise Probleme vorprogrammiert. Mit DI hat das Ganze IMHO nix zu tun. Bei richtigem DI gibts keine statischen Abhängigkeiten, sondern die erforderlichen Objekte werden im Konstruktor übergeben. Diese Container-Klasse, so wie sie existiert, sollte meiner Meinung nach entsorgt werden, da sie ein Anti-Pattern ist.
      Ok. Da werde ich mir was anderes Überlegen.
      Größtenteils sollte man auf die Klasse verzichten können.


      Zitat von hellbringer Beitrag anzeigen
      Und ohne Verwendung von Namespaces ist es bei so allgemeinen Klassennamen wie "Core", "Container", usw. ist es nur eine Frage der Zeit, bis es zu Namenskonflikten kommt.
      Da muss ich widersprechen.
      Die Klassen sind Verzeichnis mäßig aufgebaut, so das es es keine Namenskonflikte möglich sind, es sei denn, die Klasse ist falsch benannt.

      Kommentar


      • #4
        Zitat von TheIngenieur Beitrag anzeigen
        Da muss ich widersprechen.
        Die Klassen sind Verzeichnis mäßig aufgebaut, so das es es keine Namenskonflikte möglich sind, es sei denn, die Klasse ist falsch benannt.
        Das Problem hierbei ist, dass Klassen wie "Core" und "Container" keinen eigenen Namespace haben und somit faktisch im Root-Namespace registriert werden, also \Core und \Container. Da kann es eben passieren dass diese mit anderen Klassen, die ebenfalls keinen Namespace haben, kollidieren. Verzeichnisse schützen nicht vor solchen Kollisionen da es PHP egal ist wo deine Klassen "physisch" platziert sind. Mein Tipp: ordentliches Autoloading (PSR-7) und Namespaces verwenden. Kann composer out-of-the-box.

        Was mir beim groben Durchschauen aufgefallen ist: Container extends Base?! Vererbung auf diese Art anzuwenden ist meist schon der Anfang vom Untergang.
        [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

        Kommentar


        • #5
          ich hab das nicht so richtig verstanden, wieso nutzt das ding docker für phpstan und unit tests.wiso brauchst du docker zum entwikeln ?
          ist doch nur php.
          wenn das ganze ding auf docker laufen würde und nue eine api zur verfügunstellt ok, aber so ?

          Kommentar


          • #6
            Zitat von lottikarotti Beitrag anzeigen
            Das Problem hierbei ist, dass Klassen wie "Core" und "Container" keinen eigenen Namespace haben und somit faktisch im Root-Namespace registriert werden, also \Core und \Container. Da kann es eben passieren dass diese mit anderen Klassen, die ebenfalls keinen Namespace haben, kollidieren. Verzeichnisse schützen nicht vor solchen Kollisionen da es PHP egal ist wo deine Klassen "physisch" platziert sind. Mein Tipp: ordentliches Autoloading (PSR-7) und Namespaces verwenden. Kann composer out-of-the-box.

            Was mir beim groben Durchschauen aufgefallen ist: Container extends Base?! Vererbung auf diese Art anzuwenden ist meist schon der Anfang vom Untergang.
            Ah, jetzt verstehe ich. Werde das umsetzen, bei der weiteren Entwicklung. Den Composer benutze ich nicht. Gehört zur Grundidee des CMS.
            Das Base im Container sollte verschwinden können. Die Base Class ansich benötige ich für das Event System, um Daten vom Anfang bis Ende der Methode beutzen zu können.
            Der Container wird überarbeitet und zum echten DIC.


            ich hab das nicht so richtig verstanden, wieso nutzt das ding docker für phpstan und unit tests.wiso brauchst du docker zum entwikeln ?
            ist doch nur php.
            wenn das ganze ding auf docker laufen würde und nue eine api zur verfügunstellt ok, aber so ?
            Insbesondere die Devilbox stellt eine leicht zu konfigurierende XAMP Umgebung dar. Die Docker Komponenten stellen die Dienste zur Verfügung. Programmierung, Konfigurierung etc. findet weiterhin local statt. Ich benutzte keinen Composer, daher Docker für phpstan und Unit Tests.
            Aber das Nutzen ist Geschmackssache, sonst gäbe es nicht beide Möglichkeiten.

            Kommentar


            • #7
              Zitat von TheIngenieur Beitrag anzeigen
              - OOP
              - DRY
              - KISS
              - DIC
              Warum ist das hier SRP (steht in der README.md)?
              https://github.com/phpCraftBox/phpcr...ud.php#L3-L617

              DIC? Kann ich bislang nicht erkennen. Oder habe ich bislang nur an der falschen Stelle geschaut?
              Und KISS sehe ich auch eher nicht. Btw. warum glaubst du, dass dein Code KISS ist?

              Und "protected" Properties. Auch mEn kein so guter Ansatz, wenn man so auf Architektur bedacht ist (was ich zumindest auf jeden Fall schon mal gut finde!)
              Heißt im Prinzip, dass du überall vorsiehst, dass man von Klassen ableiten können soll, statt Leute aktiv zu entmutigen eben das zu tun.

              Vielleicht solltest du das weniger so klingen lassen, als würde man diese Eigenschaften in einem Code wiederfinden, sondern eher, dass du diese Eigenschaften anstrebst?

              Zitat von TheIngenieur Beitrag anzeigen
              Den Composer benutze ich nicht. Gehört zur Grundidee des CMS.
              Dateinamen wie Xyz.class.php zeigen einem gleich was abgeht. Wozu Standards, wenn seinen eigenen tausendsten Standard promoten kann.

              Zitat von TheIngenieur Beitrag anzeigen
              Der Container wird überarbeitet und zum echten DIC.
              https://github.com/phpCraftBox/phpcr...ss.php#L20-L62
              https://github.com/phpCraftBox/phpcr...ud.php#L96-L99
              Das ist btw. ein Service-Locator, kein DI-Container. Aber du schriebst ja schon, dass du das umbauen willst.

              Schau dir das hier lieber an: https://php-di.org/
              Insbesondere den Autowiring-Aspekt. Das baust du nicht eben schnell nach. Und du wirst dich hinterher fragen, wie du die ganze Zeit davor gearbeitet hat. Glaub es mir.

              Zitat von TheIngenieur Beitrag anzeigen
              Ich benutzte keinen Composer, daher Docker für phpstan und Unit Tests.
              Und nachts ist kälter als draußen.
              Kannst du mir einen nachvollziehbaren Grund nennen, warum man a) für so ein Projekt kein composer verwenden sollte und sich b) composer und docker widersprechen?

              Kommentar


              • #8
                Aber das Nutzen ist Geschmackssache, sonst gäbe es nicht beide Möglichkeiten.
                composer ist ein package installer. docker ist eine softwrae zur containervisualisierung
                ich sehe da deutliche unterschiede und nicht eine wahl nach geschmackssache

                Kommentar


                • #9
                  Zitat von rkr Beitrag anzeigen

                  Warum ist das hier SRP (steht in der README.md)?
                  https://github.com/phpCraftBox/phpcr...ud.php#L3-L617

                  DIC? Kann ich bislang nicht erkennen. Oder habe ich bislang nur an der falschen Stelle geschaut?
                  Das es kein DIC ist, darauf hat mich schon hellbringer hingewiesen.

                  Zitat von rkr Beitrag anzeigen

                  Und KISS sehe ich auch eher nicht. Btw. warum glaubst du, dass dein Code KISS ist?
                  Ich dachte, das der Code KISS und SRP ist.
                  Werde das noch einmal genauer durchgehen.

                  Zitat von rkr Beitrag anzeigen

                  Und "protected" Properties. Auch mEn kein so guter Ansatz, wenn man so auf Architektur bedacht ist (was ich zumindest auf jeden Fall schon mal gut finde!)
                  Heißt im Prinzip, dass du überall vorsiehst, dass man von Klassen ableiten können soll, statt Leute aktiv zu entmutigen eben das zu tun.
                  War eine Mischung aus Gewohnheit und zu sehr auf das einhalten der Architektur von anderen beacht.

                  Zitat von rkr Beitrag anzeigen

                  Vielleicht solltest du das weniger so klingen lassen, als würde man diese Eigenschaften in einem Code wiederfinden, sondern eher, dass du diese Eigenschaften anstrebst?
                  Werde ich ändern.

                  Zitat von rkr Beitrag anzeigen

                  https://github.com/phpCraftBox/phpcr...ss.php#L20-L62
                  https://github.com/phpCraftBox/phpcr...ud.php#L96-L99
                  Das ist btw. ein Service-Locator, kein DI-Container. Aber du schriebst ja schon, dass du das umbauen willst.

                  Schau dir das hier lieber an: https://php-di.org/
                  Insbesondere den Autowiring-Aspekt. Das baust du nicht eben schnell nach. Und du wirst dich hinterher fragen, wie du die ganze Zeit davor gearbeitet hat. Glaub es mir.
                  Mache ich derzeit, PHP DI Anschauen,
                  Das Hinterfragen macht wohl jeder, wenn man seinen Code nach einer Weile wieder anschaut. Man lernt stets dazu,
                  ich Informiere mich derzeit über Autowiring, und das was ich bisher gefunden habe, scheint nicht kompliziert zu sein.
                  Aber PHP DI ist ja kein kleines Script sondern eine mächtigeres Script.

                  Zitat von rkr Beitrag anzeigen

                  Und nachts ist kälter als draußen.
                  Kannst du mir einen nachvollziehbaren Grund nennen, warum man a) für so ein Projekt kein composer verwenden sollte und sich b) composer und docker widersprechen?
                  [/QUOTE]

                  Wegen a: Ist ebend eine Bastel Box, salopp gesagt, da wird das reingebastelt. In anderen Projekten würde ich den Composer benutzen.
                  Auch versuche ich hier, den User von der Console fern zu halten. Und suche nebenbei, den Composer direkt aus dem Script anzusprechen.

                  Zu b: Das ist falsch rüber gekommen, Sie wiedersprechen sich nicht, es ist Geschmackssache.

                  Kommentar


                  • #10
                    Zitat von tomBuilder Beitrag anzeigen

                    composer ist ein package installer. docker ist eine softwrae zur containervisualisierung
                    ich sehe da deutliche unterschiede und nicht eine wahl nach geschmackssache
                    Ich kenne den Unterschied der Technik.
                    Es geht mir lediglich um die Nutzung, nicht um die Technik dahinter.

                    Kommentar


                    • #11
                      Zitat von TheIngenieur Beitrag anzeigen
                      Ah, jetzt verstehe ich. Werde das umsetzen, bei der weiteren Entwicklung. Den Composer benutze ich nicht. Gehört zur Grundidee des CMS.
                      Composer ist das Standardtool wenn es um Autoloading und Paketverwaltung in PHP geht. Composer nicht zu nutzen bringt dir und deinen Usern rein gar nichts, aber jede Menge Nachteile. Ich lese hier immer wieder davon dass Leute sich bewusst dafür entscheiden Composer (o.ä.) nicht zu verwenden und das als Vorteil oder Feature verkaufen wollen. Ich halte das für ein KO-Kriterium um ein Framework gar nicht erst anzufassen, weil es sich bewusst vom etablierten PHP-Ökosystem isolieren will.

                      Es hat auch keinerlei nutzen wenn du das Routing oder einen DIC selbst programmierst. Mit PHP-DI gibt es bereits ein sehr gute Implementierung die alle erdenklichen Features mitbringt.
                      [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                      Kommentar


                      • #12
                        Zitat von lottikarotti Beitrag anzeigen
                        Composer ist das Standardtool wenn es um Autoloading und Paketverwaltung in PHP geht. Composer nicht zu nutzen bringt dir und deinen Usern rein gar nichts, aber jede Menge Nachteile. Ich lese hier immer wieder davon dass Leute sich bewusst dafür entscheiden Composer (o.ä.) nicht zu verwenden und das als Vorteil oder Feature verkaufen wollen. Ich halte das für ein KO-Kriterium um ein Framework gar nicht erst anzufassen, weil es sich bewusst vom etablierten PHP-Ökosystem isolieren will.

                        Es hat auch keinerlei nutzen wenn du das Routing oder einen DIC selbst programmierst. Mit PHP-DI gibt es bereits ein sehr gute Implementierung die alle erdenklichen Features mitbringt.
                        Ich kenne die Vorteile von Composer und PHP-DI, in anderen Projekten würde ich es auch nutzen.
                        Als Vorteil oder Feature will ich es nicht verkaufen. Das CMS ist ebend eine Bastelbox, wie der Name schon sagt. Da wäre es doch langweilig, Composer oder anders zu nutzen.

                        Kommentar


                        • #13
                          Zitat von TheIngenieur Beitrag anzeigen
                          Ich kenne die Vorteile von Composer und PHP-DI, in anderen Projekten würde ich es auch nutzen.
                          Als Vorteil oder Feature will ich es nicht verkaufen. Das CMS ist ebend eine Bastelbox, wie der Name schon sagt. Da wäre es doch langweilig, Composer oder anders zu nutzen.
                          Die Argumentation verstehe ich nicht ganz, aber wollte auch kein großes Fass aufmachen Du suchst ja scheinbar Projekthilfe, wie schon einige vor dir, und das klappt aus meiner Sicht am besten wenn das Projekt auch irgendwie zukunftsträchtig ist. Ein "Bastelbox"-CMS braucht imho niemand.
                          [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                          Kommentar


                          • #14
                            Zitat von lottikarotti Beitrag anzeigen
                            Die Argumentation verstehe ich nicht ganz, aber wollte auch kein großes Fass aufmachen Du suchst ja scheinbar Projekthilfe, wie schon einige vor dir, und das klappt aus meiner Sicht am besten wenn das Projekt auch irgendwie zukunftsträchtig ist. Ein "Bastelbox"-CMS braucht imho niemand.
                            Man kann alles Zusammenbasteln.
                            Wer auf den Composer zurückgreifen möchte, der kann das auch tun. Es ist ja nicht verboten. Das Grundsystem verzichtet nur darauf. Für die Custom Applications, Plugins etc. wurde ein extra Verzeichnis erstellt, wodurch normalerweise keine Kollision entstehen sollte. Ich sollte nur schauen, das die Autoloads sich Vertragen.

                            Kommentar


                            • #15
                              Zitat von TheIngenieur Beitrag anzeigen
                              Ich kenne die Vorteile von Composer und PHP-DI, in anderen Projekten würde ich es auch nutzen.
                              Als Vorteil oder Feature will ich es nicht verkaufen. Das CMS ist ebend eine Bastelbox, wie der Name schon sagt. Da wäre es doch langweilig, Composer oder anders zu nutzen.
                              Ich compiliere und patche mir progarmme, den kernel, X auf linux auch - nicht mal über gentoo - weil ich es einfach kann;
                              jedenfalls wenn mir super langweilig ist und keien andere Beschäftigung möglich ist.
                              I solch einem Fall käme ich nicht im traum drauf irgendwo irgendeine Hilfe zu erfragen.
                              Denn das willst Du ja, dass Dir jemand die Arbeit macht.
                              Viel Glück, alleine die in #5 Erklärte Verwunderung hat mich davon abgehalten, den Code abzuschauen.

                              Kommentar

                              Lädt...
                              X