Ankündigung

Einklappen
Keine Ankündigung bisher.

Neues kleines Framework

Einklappen

Neue Werbung 2019

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

  • #16
    Zitat von ehc_master Beitrag anzeigen
    @abo: mir geht es wirklich vorrangig um den lerneffekt und ggf. irgendwann als referenz und als basis für folgende projekte nutzen. ich hab schon versch. frameworks benutzt, daher will ich jetzt einfach etwas tiefer eintauchen ... die o.g. "features" werden sich in der nächsten zeit sicher ändern, aber ich musste mir erstmal irgendein ziel stecken ... und hey, es macht seit ca n monat gut spaß, hab diverse selbstgesteckte meilensteine erreicht und geht immer weiter voran... allerdings wird mein backlog auch immer größer
    Dann wünsch ich dir viel Erfolg bei dem Framework und viele Lernerfolge
    Ansonsten schliesse ich mich sgoetsch an
    Zitat von sguetsch Beitrag anzeigen
    Find's interessant und würde mal im Repo vorbeischauen *auf Updates wart*

    Kommentar


    • #17
      Zitat von rkr Beitrag anzeigen
      Nein.
      Was mich an diesen Diskussionen immer stört ist dass das meistens à la "Viele Wege führen nach Rom, nur meiner ist sicher der einzig richtige" sind.
      [URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]

      Kommentar


      • #18
        Zitat von ChristianK Beitrag anzeigen
        Was mich an diesen Diskussionen immer stört ist dass das meistens à la "Viele Wege führen nach Rom, nur meiner ist sicher der einzig richtige" sind.
        Diese Diskussion ist völlig sinnlos. Es gibt sicher mehr als 100 bekannte PHP-Frameworks. Davon brauchen wir vielleicht 10, die wirklich unterschiedliche Anwendungsfälle abdecken. Der Rest verfolgt mehr oder weniger redundant die gleichen Ziele.

        Was ist denn ein Framework überhaupt? In den meisten Fällen ein HTTP-Core mit Routing, Templating und Helpern, der die Grundfunktionen einer PHP-Anwendung ohne viel Konfiguration zugänglich machen soll. Einige große Frameworks wie Laravel, Symfony oder Zend (aber auch andere) bestehen wiederrum aus Einzelkomponenten, die man sich gebündelt, aber auch einzeln in sein Projekt holen kann. Da jedes Nicht-Standard-Projekt eine gewisse Einzigartigkeit hat, ist es teilweise auch notwendig, Teile von verschiedenen "Frameworks" zu vermischen.

        Worauf ich eigentlich hinaus wollte, ist aber etwas anderes. Normal hast du bis vor ein paar Jahren immer ein Framework genutzt, weil da alles wie aus einem Guss war. Man sieht es an den Gehversuchen des TE, was ich damit meine. Man hat irgendwie ein Controller und der bietet dann irgendwie Referenzen zu allem, was das Framework so zu bieten hat. Und es fühlt sich cool an, weil man so leicht Zugriff auf die wesentlichen Komponenten bekommt, ohne jedes Mal mit einem gewissen Overhead alles neu zu instanziieren und konfigurieren.

        Nun, das ist mittlerweile anders. Heute stört sowas nur, weil man damit auch eine gewisse Freiheit aufgeben muss. Man bekommt durch so ein Framework zwar leicht Zugriff auf alles, ist aber auch an die Herangehensweise des Frameworks gebunden. Die Bindung ist zwar weich, da man auch jederzeit etwas eigenes mit einbauen kann. Sie wird aber hart, wenn man in einem größeren Team arbeitet, oder ein darauf aufbauendes Projekt von einer Vielzahl an unabhängigen Entwicklern genutzt werden sollen, wobei das Framework dann das Denkmuster vorgibt, was Chaos verhindern soll. Dabei kann ich mir gleicht den HTTP-Core von Symfony, Zend, Slim oder Laravel holen, und mit DI alles weitere ins Projekt holen, wie Doctrine, Propel, Swift, Twig und alles, was man beispielsweise auf dieser Seite findet.

        Wozu überhaupt ein eigenes Framework? Wann macht ein Framework überhaupt Sinn?

        Nutzen: Zunächst mal sollte jeder, der ein eigenes Framework baut, erklären können, was das eigene Framework macht, was andere nicht machen. Das, was hier passiert, sieht sehr nach Codeigniter aus. Ein extrem veralteter Ansatz, der spätestens in den PHP 5.0-Zeiten seinen Ursprung hat. Wenn ein Framework keinen Nutzen für Entwickler bildet, dann macht es auch keinen Sinn, eines zu entwickeln. Das klassische neuerfundene Rad.

        Lerneffekt: Welchen Effekt hat es, die Fehler, die andere gemacht haben, zum hundertsten Mal zu wiederholen? Wäre es nicht besser, man schaut sich die bestehenden Lösungen an und versucht zu verstehen, was, wieso und warum? Einige Frameworks sind seit mehr als 10 Jahren in der Entwicklung und haben - gerade auch auf Grund der hohen Nutzerzahlen - die allermeisten Probleme schon gelöst. Und wenn nicht, dann existieren bereits Dokumente, die einen Lösungsweg beschreiben. Und welchen Effekt hat es ein Framework zu schreiben, dass später niemand gebrauchen kann? Das verbraucht Zeit und bringt außer ein paar Aha-Effekten rein gar nichts. Aber gut - wenn das ein Lernpfad ist, der schlussendlich irgendwie zu einem annehmbaren Ziel führt, dann soll es so sein. Das Internet mit seinen Gehversuchen zu verschmutzen trägt mEn aber weniger zum Lerneffekt bei, gerade weil ja schon so ziemlich alles Dokumentiert wurde.

        Dokumentation: Das, was Nutzer an einem Framework vor allem reizt, ist eine ausgereifte Dokumentation. Sollte hier wirklich mit einem neuen Framework der große Wurf gelingen, dann weiß immer noch niemand, wie man das Framework verwendet. Und eine gute Dokumentation zu schreiben kann viel aufwändiger sein, als das eigentliche Projekt. Denn man muss dem User ein Bild von dem Vermitteln, wie man das Framework in jeder nur erdenklichen Hinsicht benutzt. Und sobald ein Framework eine gewisse Größe übersteigt, finden sich immer Nutzer, die einen Anwendungsfall haben, der Änderungen an den Kernelementen eines Frameworks notwendig macht.

        Support: Gerade der letzte Punkt ist sehr wichtig. Software ist nie fertig - das sollte mittlerweile bekannt sein. Ein tolles Beispiel in dieser Hinsicht ist Angular. Angular hat mit seiner Lösung allerdings Neuland betreten. Seinerzeit gab es nichts vergleichbares. Und man sieht an den Nutzerzahlen, wie abgefahren das Konzept war und ist. Aber am Ende hat die Lösung viele Macken. Die sind teilweise so stark, dass die Version 2.0 von Angular so ziemlich alle wesentlichen Konzepte neu implementiert hat und so manche Idee nur noch in Teilen wiederverwendet werden kann. Auf der Angular-Idee sind neue Frameworks entstanden. Wie beispielsweise Vue.js. Vue.js - obwohl es eine umfangreiche Vorlage hatte und viel jünger ist - hat auch nicht alles richtig gemacht - aber vieles besser. Allerdings ist das Team hinter Vue.js groß und verlässlich genug, damit unabhängige Entwickler(-Teams) dieser Komponente ihr Vertrauen schenken.

        Warum also sich von dem Gedanken eines Frameworks trennen?

        Da gibt es eine Reihe von Gründen. Das in der PHP-Welt verhältnismäßig neue Composer erlaubt, dass Projekte ihre Kernkomponenten frei zusammenstellen können. So ist man nicht mehr alles auf Gedeih und Verderb an ein monolithisches Framework gebunden. Eine Anwendung ist von Anfang an modular aufgebaut - zumindest was wie Kernkomponenten betrifft.

        Zeit vergeht. Und mit der Zeit etablieren sich neue Konzepte. PHP7 und 7.1 werden neue Denkmuster bei der Anwendungserstellung nach sich ziehen. Was heißt, dass Anwendungen mit der Zeit anders aussehen werden. Sie werden von Konzepten der neuen Sprachversionen Gebrauch machen und die Kernkomponenten der Anwendung werden sich ebenfalls weiterentwickeln. Es ist schmerzhaft, ein Framework zu ersetzen. Weniger schmerzhaft ist es, einzelne Komponenten Stück für Stück zu ersetzen. Der Bruch, den PHP5.3 (Closures, Namespaces, Exceptionnesting), 5.4 (Traits, Closures mit $this) oder 5.5 (Generatoren, ::class, finally) jeweils gebracht haben (auch wenn der von 5.3 und 5.4 am gravierensten war), haben viele Anwendungen erst mal auf Links gedreht, weil auch plötzlich ganz neue Möglichkeiten ergeben haben, Anwendungslogik auszudrücken.

        Was also tun, statt ein Framework zu entwickeln?

        Schau dir andere Sprachen an. Besonders die aufstrebenden Sprachen wie Elixir oder . Es ist ohnehin besser mehr als eine Sprache zu beherrschen. Was aber wirklich wichtig ist, ist, über den Tellerrand zu schauen und neue Lösungsansätze kennenzulernen. Diese neuen Lösungsansätze können dann ggf. in die PHP-Welt übernommen werden. Oder man beteiligt sich an vorhandenen Projekten. Arbeit gibt es genug.

        Kommentar


        • #19
          ich wollte gestern noch schreiben... der sinn und einsatz eines frameworks sollte hier nicht bestandteil der diskussion werden... dazu gibt es unendlich viele andere diskussionen zu dem thema im web
          hardcore will never die

          Kommentar


          • #20
            zum einen nochmal danke für den link
            zum anderen hast du natürlich recht und man könnte aus deinem beitrag eigentlich eine neue diskussion machen und irgendwo anpinnen
            hardcore will never die

            Kommentar


            • #21
              Mal mein Senf dazu: Ich muss leider dem zustimmen: Es gibt tausend Frameworks und ich könnte mir nicht vorstellen, was noch nicht abgedeckt ist. Und wie hier schon erwähnt wurde, ist der monolithische Ansatz mittlerweile veraltet.

              Schau Dir Symfony an: Insgesamt zwar ein Fullstack-Framework, aber im Prinzip vestehend aus Einzelkomponenten, die sich völlig losgelöst voneinander verwenden lassen (Man schaue sich in diesem Zusammenhang Silex an).

              Aber: Für den Lerneffekt ist so etwas, was der TE hier macht, unbezahlbar. Absolut Daumen hoch dafür! Ich habe zu meinen Anfängen genau dasselbe gemacht und habe damals unheimlich viel dadurch gelernt. Und heute hat man außerdem den Vorteil, dass sich die komplette Szene viel stärker professionalisiert hat, was sich in der Qualität der verfügbaren Vorbilder und Quellen niederschlägt.

              @ehc_master: Als Referenz allerdings würden sich konkrete Applikationen oder Bibliotheken für spezielle Einsatzzwecke viel besser eignen. Dieses Framework, dass Dir hier vorschwebt, wirst Du niemals in einem produktiven Zustand bringen. Mach lieber etwas Kleines, das Du dafür auch durchziehen kannst.

              Kommentar


              • #22
                Witzig ist, dass sogar Frameworks existieren, die in C implementiert (extension) sind und PHP-Code bereitstellen, um sich einen Performance-Vorteil zu verschaffen Ganz interessant finde ich Phalcon. Ist natürlich nix für die normalen Free-Hoster, aber mit nem eigenen Server geht da die Post ab
                Tutorials zum Thema Technik:
                https://pilabor.com
                https://www.fynder.de

                Kommentar


                • #23
                  Nichts außergewöhnliches. Phalcon wurde auf Basis von Zephir entwickelt, womit jeder PHP Module etc. in einer an PHP angelehnten Sprache schreiben kann. Diese werden dann in C portiert werden und anschließend kompiliert. Ist eine Möglichkeit die Performance Problematik des Standard PHP-Interperters zu umgehen. Die andere ist es, wie z.B. Facebook mit HipHop den PHP Code in C++ Code zu übersetzen und dann ebenfalls zu kompilieren.
                  "Software is like Sex, it's best if it's free." - Linus Torvalds

                  Kommentar


                  • #24
                    Wobei das mit der Performance sich mit PHP 7 vermutlich stark relativiert hat. Wenn man bedenkt, wie fest Phalcon hinterherhinkt (oder es hinkte, jedenfalls als ich das letzte Mal drauf schaute war da noch kein Wort von PHP 7).

                    Ich konnte einen durchschnittlichen Boost von 30-50% mit der Umstellung auf PHP 7 verbuchen.
                    [URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]

                    Kommentar


                    • #25
                      Zitat von ChristianK Beitrag anzeigen
                      Wobei das mit der Performance sich mit PHP 7 vermutlich stark relativiert hat. Wenn man bedenkt, wie fest Phalcon hinterherhinkt (oder es hinkte, jedenfalls als ich das letzte Mal drauf schaute war da noch kein Wort von PHP 7).

                      Ich konnte einen durchschnittlichen Boost von 30-50% mit der Umstellung auf PHP 7 verbuchen.
                      Dann schau nochmal vorbei, letztes Wochenende gabs dort das "große" Update auf 3.0. Ein primärer Punkt dieses Updates war PHP7 Kompatibilität.
                      Dessen ungeachtet hängt es an einigen Stellen leider trotzdem hinterher, mal im Vergleich zu Laravel fallen Dokumentation oder Tutorials leider eher schlecht aus. Gerade "laracasts" haben der Verbreitung von Laravel denke ich unglaublich geholfen. Für die Profis hier reicht die schriftliche Dokumentation vermutlich nach, aber gerade als Anfänger in Bezug auf Frameworks kann man sich dort in wenigen Stunden einen sehr guten Wissenstand aneignen und dann danach direkt anwenden.

                      Zitat von rkr
                      Lerneffekt: Welchen Effekt hat es, die Fehler, die andere gemacht haben, zum hundertsten Mal zu wiederholen? Wäre es nicht besser, man schaut sich die bestehenden Lösungen an und versucht zu verstehen, was, wieso und warum?
                      Je nach Lerntyp sind Fehler essentiell. Natürlich muss man nicht jede Kleinigkeit erstmal falsch machen, aber für mich hat es sich schon oft als hilfreich herausgestellt erst einmal den "falschen" Ansatz zu fahren und dann am eignen Leib zu spüren warum dieser Ansatz falsch ist und wie der "richtige" Ansatz das anders macht. Das ist ein recht "aufwändiger" Lernweg, dafür hat man die Erkentnisse danach bedeutend besser verinnerlicht als beim "richtige Ansatz anschauen und versuchen zu verstehen".

                      Kommentar


                      • #26
                        Yup, genau das ist/war der Plan. Es ist zwar aufwendiger, dafür erhalte ich aber ein besseres Backgroundwissen.

                        Produktiv läuft es die ganze Zeit schon. Ich habe im Projekt(aktueller Kunde) das Framework gebaut. Klar musste fast alles neu entwickelt werden, jedoch konnte ich so Teile die auch für den Kunden wichtig sind, in Rechnung stellen irgendwie müssen wir ja och watt essen.

                        Ich hatte aufjedenfall damit viele Erfahrungen gesammelt und bin auch langsam an dem Punkt gelangt, die Entwicklung einzustellen. Kunde/Projekt ist vorbei, Framework kann man noch weiter optimieren, was aber nicht unbedingt viel bringen würde, da es den von mir und vom Kunden geforderten Ansprüchen übertrifft.

                        Es als Opensource-Framework und Referenz zu nutzen bin ich auch von weg, da es nichts mit aktuellen Entwicklungen zutun hat.
                        hardcore will never die

                        Kommentar


                        • #27
                          Freut mich, dass es so gelaufen ist, Du Erfahrungen damit gesammelt hast und nicht (wie etliche andere, denen ich schon begegnet bin) dran hängen bleibst
                          *Daumen hoch*

                          Kommentar


                          • #28
                            Hi,

                            ich kann es auch nur unterstützen, wenn man Sachen selbst programmieren möchte. Nur so kann man wirklich was lernen. Das öfters gebrachte Argument, "lass das, schau Dir ein fertiges Framework an, hier siehst du wie man es richtig macht!" ist, mit Verlaub, schwachsinnig. Fremdcode anschauen hat nicht einmal den Bruchteil des Lerneffektes im Gegensatz zum selbst Programmieren (Hürden erkennen, Hürden umschiffen, usw.).

                            Natürlich bekommt man mit hoher Wahrscheinlichkeit kein so tolles Framework am Ende hin, aber was solls? Nur vom Code anschauen lernt man so gut wie nichts, außer man kann schon sehr fortgeschritten programmieren, aber das ist was anderes, das sind andere Vorraussetzungen. Deshalb gehen mir hier im Forum manche Antworten gehörig auf den Keks, es wird mit solchen Antworten jegliche Eigeninitiative und Lernbereitschaft unterdrückt.
                            There are 10 kind of people: those who understand binary and those who don't.

                            Kommentar


                            • #29
                              Zitat von Talwin Beitrag anzeigen
                              ich kann es auch nur unterstützen, wenn man Sachen selbst programmieren möchte. Nur so kann man wirklich was lernen. Das öfters gebrachte Argument, "lass das, schau Dir ein fertiges Framework an, hier siehst du wie man es richtig macht!" ist, mit Verlaub, schwachsinnig. Fremdcode anschauen hat nicht einmal den Bruchteil des Lerneffektes im Gegensatz zum selbst Programmieren (Hürden erkennen, Hürden umschiffen, usw.).
                              Sorry, das ist bullshit. Bei blutigen Anfängern, die fremden Code nur schwer nachvollziehen können, mag das vielleicht zutreffen - die sollten aber erstmal die Grundlagen der Sprache lernen. Als fortgeschrittener Entwickler, und ich habe sehr früh damit begonnen fremden Code zu lesen, muss ich sagen, dass gerade der Blick in andere Projekte oftmals sehr inspirierend und für mich nicht mehr wegzudenken ist. Man entdeckt sehr oft neue Ansätze auf die man gar nicht selbst gekommen wäre, findet interessante Möglichkeiten Patterns auf eine neue Art einzusetzen, stößt auf Lösungen die man völlig anders umgesetzt hätte und erhält wertvolle Einblicke in die Möglichkeiten einer Programmiersprache, die einem so vielleicht gar nicht bewusst waren. Selbst bei der Strukturierung von Projekten kann man hier sehr viel lernen.

                              Zitat von Talwin Beitrag anzeigen
                              Natürlich bekommt man mit hoher Wahrscheinlichkeit kein so tolles Framework am Ende hin, aber was solls? Nur vom Code anschauen lernt man so gut wie nichts, außer man kann schon sehr fortgeschritten programmieren, aber das ist was anderes, das sind andere Vorraussetzungen. Deshalb gehen mir hier im Forum manche Antworten gehörig auf den Keks, es wird mit solchen Antworten jegliche Eigeninitiative und Lernbereitschaft unterdrückt.
                              Natürlich muss man das was man "gelesen" hat auch erstmal in der Praxis anwenden um es zu begreifen. Ich sehe aber keinen Grund warum Anfänger (die über die Grundlagen der Sprache verfügen und diese verstehen) nicht damit beginnen sollten, sich "guten Code" - oder "gute Lösungen" - anzusehen um von den Erfahrungen anderer Entwickler zu lernen. Ich persönlich mache ungerne Fehler die andere schon 1000x vor mir gemacht haben. Und man muss auch nicht alle Fehler machen um langfristig zu begreifen warum eine Lösung besser ist als die andere.

                              Mein Tipp: das Lesen von fremden Code als festen Bestandteil in den Lernprozess einbauen und alles was man entdeckt sofort selbst ausprobieren und verinnerlichen. Fragen kann man später immer noch stellen.
                              [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                              Kommentar


                              • #30
                                Hallo!

                                Zitat von lottikarotti Beitrag anzeigen
                                (...) das Lesen von fremden Code als festen Bestandteil in den Lernprozess einbauen und alles was man entdeckt sofort selbst ausprobieren und verinnerlichen (...)
                                Das habe ich in VBA von Anfang an gemacht, und auch bei Excelformeln. Bei RibbonX hatte ich nur eine Exceldatei (von Hans W. Herber) mit der man eigene Tabs erstellen konnte, da hatte ich die Dateien auf "Veränderungen" analysiert mangels Programmierinformationen zu diesem Thema.

                                Gruß, René

                                Kommentar

                                Lädt...
                                X