Ankündigung

Einklappen
Keine Ankündigung bisher.

PHP Framework Codeigniter

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

  • PHP Framework Codeigniter

    Hey,

    Was haltet ihr denn vom PHP Framework Codeigniter ?
    Hat jemand denn schon Erfahrungen damit gemacht?
    Wäre dieses Framwork eure erste Wahl wenn man anfängt mit Frameworks zu programmieren?

    Freue mich auf hilfreiche Antworten.

    Moonracer


  • #2
    MOD: Verschoben von Off-Topic
    Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
    PHP.de Wissenssammlung | Kein Support per PN

    Kommentar


    • #3
      Zitat von Moonracer Beitrag anzeigen
      Hey,

      Was haltet ihr denn vom PHP Framework Codeigniter ?
      Hat jemand denn schon Erfahrungen damit gemacht?
      Wäre dieses Framwork eure erste Wahl wenn man anfängt mit Frameworks zu programmieren?

      Freue mich auf hilfreiche Antworten.

      Moonracer
      Das Framework ist tot, ich selbst, habe damals mit Kohana angefangen, welches ein Community Weiterführung von Codeigniter ist. Und selbst der ist mittlerweile Tot.

      Das Framework bietet einige Interessante ansätze gerade für Anfäger, jedoch wirst du damit später nichts anfangen können.

      Eher würde ich an deiner Stelle mir Slim Framework ansehen. Es ist Modern und ist ähnlich wie andere Aufgebaut, somit ist die Umstelung(wenn man es zb für den Beruf benötigt) nicht sehr schwer.

      Jedoch ist es schon etwas komplexer wenn man nicht weiß was Namespaces sind, was und wozu ein DI Container ist usw.
      apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp

      Kommentar


      • #4
        Was BlackScorp gesagt hat.
        Allerdings würde ich bei der Empfehlung eher zu Laravel tendieren. Dort ist schon alles was man als Anfänger braucht von Anfang an mit dabei (ORM, Template, Queue, etc.) und nutzbar (entsprechend auch gut dokumentiert). Kann als Anfänger schnell frustrierend werden wenn man diverse Abhängigkeiten erst noch inkludieren und konfigurieren muss und alles dafür zusammengoogeln muss.

        Just my 2 cents.
        "Software is like Sex, it's best if it's free." - Linus Torvalds

        Kommentar


        • #5
          Info am Rande:

          Zitat von Zeichen32 Beitrag anzeigen
          Und ich möchte noch anmerken das Silex demnächst eingestellt wird, da Symfony4 mit Flex ja jetzt die Micro-Kernel Architektur mitbringt. Ich würde daher nicht unbedingt auf Silex bei einem neuen Projekt setzen.
          Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
          PHP.de Wissenssammlung | Kein Support per PN

          Kommentar


          • #6
            Oder garnicht erst Frameworks einsetzen, ich stelle gerade alle meine Projekte um auf PHP-DI und die http://thephpleague.com/ packages, seit dem ich das mit Silex gehört und nun schon ein Zweites Framework EOL erreicht hab, schließe ich mit dem Thema ab.

            Frameworks sind Cool für Agenturen und Projekte die jetzt schnell umgesetzt werden müssen, abgeliefert werden müssen und dann feierabend.

            Hast du, oder willst du ein Projekt über mehrere Jahre pflegen(4+) dann lass die Finger vom Framework und nutze einzelne Libs.


            Und die Laravel Fanboys brauchen mir erst garnicht zu erzählen wie Toll das alles doch ist, sobald ein Minore release rauskommt, muss man sich an Guides ranhalten und schauen was man ändern muss. Oder man fixiert die Version in composer aber das ist dann auch blöd.
            apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp

            Kommentar


            • #7
              Das kann ich so nicht unterschreiben. Seit Jahren setze ich alle meine Projekte mit Symfony an und bisher hatte ich noch nie Probleme auf ein Major Release umzustellen. Klar ist mal hin und wieder etwas deprecated, allerdings geht eine Umstellung in 99% der Fälle ohne großen Aufwand. Ich denke mal unter Laravel ist es ähnlich.

              Und zum EOL von Silex: Eine Umstellung auf Symfony Flex sollte, wenn man das Framework richtig benutzt hat, auch ohne große Probleme möglich sein.

              Kommentar


              • #8
                Zitat von Zeichen32 Beitrag anzeigen
                Das kann ich so nicht unterschreiben. Seit Jahren setze ich alle meine Projekte mit Symfony an und bisher hatte ich noch nie Probleme auf ein Major Release umzustellen. Klar ist mal hin und wieder etwas deprecated, allerdings geht eine Umstellung in 99% der Fälle ohne großen Aufwand. Ich denke mal unter Laravel ist es ähnlich.

                Und zum EOL von Silex: Eine Umstellung auf Symfony Flex sollte, wenn man das Framework richtig benutzt hat, auch ohne große Probleme möglich sein.
                Aber als gegenStück. Ich habe mehrere Libs, die ich seit Jahren nutze, und nach einem Update dieser Libs musste ich nichts an meinem Code ändern. Es gab mal eine Umstellung als ich von Guzzle 5 auf 6 umstellte, das wars aber auch schon.


                Meine Erfahrung ist aktuell so:

                Nutze Framework, kann es entweder Sterben, oder ich muss nach einem Update mir die Zeit nehmen und die Update Guidlines zu lesen und diese auszuführen und dann gucken ob alles noch so läuft wie bisher.

                Nutze Libs, da kannst du updaten so oft du willst, auch die Major releases und nur ein Mal musste ich was ändern.


                Ich bin zu alt für diesen Scheiß, Frameworks sind für mich gestorben, einfach composer + libs die ich brauche, die Libs schön hinter Implementierungen verpacken und Kern nicht abhängig von externen Libs machen.
                apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp

                Kommentar


                • #9
                  Ein Framework wie bsp. Symfony ist ja auch nur eine Sammlung von Libraries, welche auch eigenständig genutzt werden können. Also kann ich das Argument nicht ganz nachvollziehen.

                  Außerdem haben Frameworks in den meisten Fällen auch eine Backward Compatible Promise, was es bei Libaries nicht unbedingt gibt.
                  http://symfony.com/doc/current/contr...g/code/bc.html

                  Aber es gibt ja zum glück mehrere Wege wie man zum Ziel kommt, ob nun mit oder ohne Framework.

                  Kommentar


                  • #10
                    Zitat von BlackScorp Beitrag anzeigen
                    Und die Laravel Fanboys brauchen mir erst garnicht zu erzählen wie Toll das alles doch ist, sobald ein Minore release rauskommt, muss man sich an Guides ranhalten und schauen was man ändern muss. Oder man fixiert die Version in composer aber das ist dann auch blöd.
                    Ich bin weder Laravel Fanboy noch möchte ich damit sagen dass alles an Laravel toll ist. Es war lediglich ein Vorschlag, basierend auf einer steilen Lernkurve, vernünftiger Dokumentation und großer Community (was alles für Anfänger wichtig sein dürfte).
                    Meiner Meinung nach sollte man als Entwickler sich zumindest einmal Frameworks angesehen und auch genutzt haben (was OP ja möchte). Wenn du in ein Team gesetzt wirst, das im Projekt ein Framework (was auch immer für eins) verwendet, kannst du nicht einfach die Arme verschränken und sagen dass du nur noch mit eigenem Setup basierend auf PHP-DI und PHPLeague arbeitest. Zumal man von guten Frameworks lernen kann wie prinzipiell Anwendungen strukturiert werden (können).
                    "Software is like Sex, it's best if it's free." - Linus Torvalds

                    Kommentar


                    • #11
                      Zitat von JaMa Beitrag anzeigen

                      Ich bin weder Laravel Fanboy noch möchte ich damit sagen dass alles an Laravel toll ist. Es war lediglich ein Vorschlag, basierend auf einer steilen Lernkurve, vernünftiger Dokumentation und großer Community (was alles für Anfänger wichtig sein dürfte).
                      Meiner Meinung nach sollte man als Entwickler sich zumindest einmal Frameworks angesehen und auch genutzt haben (was OP ja möchte). Wenn du in ein Team gesetzt wirst, das im Projekt ein Framework (was auch immer für eins) verwendet, kannst du nicht einfach die Arme verschränken und sagen dass du nur noch mit eigenem Setup basierend auf PHP-DI und PHPLeague arbeitest. Zumal man von guten Frameworks lernen kann wie prinzipiell Anwendungen strukturiert werden (können).
                      Nein, natürlich nicht.

                      Aber, steile Lernkurve, das kommt drauf an ob man schon erfahrungen hat. Ich wette du wusstest was Namespaces sind und was Autoloading ist als du mit Laravel anfingst. Wenn ich mir das getting started dort anschaue, kriege ich sicherlich sofort eine Applikation hin und würde auch bestimmte sachen schnell in Google finden. Das liegt aber nicht NUR an der Dokumentation sondern mehr an meinem hintergrund Wissen.

                      Es gibt so viele tolle Sachen in Frameworks die einen Neuling direkt "reinziehen" du machst hier und da paar Sachen und Zack hast du eine App. Ich habe aber mittlerweile so viele negative Erfahrungen gesammelt, dass ich einfach die Finger von lasse und jedem Neuling eher empfehle, die Basics von Framework zu verstehen, und nicht Konkret auf das Framework X.

                      Sprich: Es gibt da etwas, das nennt sich Routing, es gibt Middlewares, es gibt DI, es gibt ORM, es gibt Request/Response/MessageInterface. Und diese Dinger sind in einem Microframework in abgespeckter Variante vorhanden. Kennt man diese Elemente, kann man jedem Getting Started von jedem Framework folgen. Und wenn ein Team dann von mir möchte dass ich Zend einsetze, dann arbeite ich mich dort ein und werde nicht diesen Jobangebot direkt ablehenen weil ich ja nur Laravel kann.
                      apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp

                      Kommentar


                      • #12
                        Zitat von BlackScorp Beitrag anzeigen
                        Nutze Libs, da kannst du updaten so oft du willst, auch die Major releases und nur ein Mal musste ich was ändern.
                        Das hat recht wenig mit Frameworks an sich zu tun. So gut wie jede Library bringt bei einem Major-Release auch Breaking Changes mit - dafür ist ein Major-Release (zumindest laut semver) ja da. Das heißt aber nicht dass Upgrades grundsätzlich kompliziert sind. Beim Komponenten-Ansatz hat man allerdings den Vorteil, dass man nicht alles auf einen Schlag aktualisieren muss, sondern Komponente für Komponente austauschen kann, wann immer man es für notwendig hält.

                        Ich persönlich nutze nur noch einzelne Komponenten, weil Frameworks mir einfach zu viel bloat mitbringen. Das Grundgerüst meiner Anwendungen besteht serverseitig meistens nur noch aus einem extrem dünnen Routing / Middleware Layer. Business-Logik steckt dann entweder in eigenen PHP-Komponenten oder wird von anderen Services bereitgestellt, die dann bspw. auch mit Go, Node oder Java laufen können.

                        Kommentar


                        • #13
                          Die Diskussion ist eigentlich recht merkwürdig, wenn man auch andere Sprachen kennt, die man quasi nur mit Frameworks verwendet. Oder wer programmiert C# ohne .NET (oder Mono)? Wenn du einem C# Entwickler sagt, dass man ohne Framework besser dran ist, wird er nur den Kopf schütteln.

                          Kommentar


                          • #14
                            Zitat von lottikarotti Beitrag anzeigen
                            Das hat recht wenig mit Frameworks an sich zu tun. So gut wie jede Library bringt bei einem Major-Release auch Breaking Changes mit - dafür ist ein Major-Release (zumindest laut semver) ja da.
                            Das Ding ist, Libraries haben nie Breaking Changes, ich nutze seit 3+ Jahren Mustache als Tempalate Engine, kann jederzeit upgraden, läuft. Guzzle war bisher eine einzige Ausnahme. Ich hantiere immer noch mit alten Silex rum, weil dort Pimple umgestellt wurde und $app->share methode nicht mehr vorhanden ist, das ist Frustrierend, alles durchzugehen.

                            Klar würdest du jetzt sagen "Wo ist das Problem, einfach rechtsklick, Find in Path.. und dann ersetzen". Nun, ich beschäftige mich seit 2009 mit PHP und es wenn es so einfach wäre, hätte ich es schon längst getan.


                            Zitat von lottikarotti Beitrag anzeigen
                            Ich persönlich nutze nur noch einzelne Komponenten, weil Frameworks mir einfach zu viel bloat mitbringen. Das Grundgerüst meiner Anwendungen besteht serverseitig meistens nur noch aus einem extrem dünnen Routing / Middleware Layer. Business-Logik steckt dann entweder in eigenen PHP-Komponenten oder wird von anderen Services bereitgestellt, die dann bspw. auch mit Go, Node oder Java laufen können.
                            Da machste auch nichts falsches daran, die Libs kann man wunderbar hinter Klassen verstecken und diese dann im DI ersetzen, wenn man gegen Interfaces programmiert. Beim Framework wirds schwieriger.

                            hellbringer

                            Der Vergleich hingt, es gibt nur 1 Framework, ALLE Firmen arbeiten damit, es wird sogar in der Schule beigebracht es zu nutzen. In PHP gibts ja mehr. In C# kannste sagen "Nimm .Net damit findest du Arbeit, alle nutzen es, es ist bereits in IDEs verbaut, dein Leben wird einfacher"

                            In PHP heißt es "Nimm x es hat gute Dokumentation, Steile Lernkurve und große Community". Ich finde aber, man muss vorher wissen, was kennt die Person schon? Weis er was Composer ist? Weis er was Namespaces sind? Wie gut sind seine OOP Kentnisse? Hat er schon mal vorher mit einem Framework gearbeitet? Gibt es einen Höheren Grund wieso er das Framework X lernen will? Es sind so viele Fragen offen, stattdessen wird einfach nur sein liebling empfohlen.

                            so ich werde nichts mehr zum Thema sagen, lotti wird sowieso das letze "aber" haben
                            apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp

                            Kommentar


                            • #15
                              Zitat von BlackScorp Beitrag anzeigen
                              Das Ding ist, Libraries haben nie Breaking Changes, ich nutze seit 3+ Jahren Mustache als Tempalate Engine, kann jederzeit upgraden, läuft. Guzzle war bisher eine einzige Ausnahme.
                              Das ist Blödsinn. Ich kann dir auf Anhieb 20 Libs (nicht nur im PHP-Bereich) nennen bei denen das Gegenteil der Fall ist, darunter bspw. barbushin/php-imap oder rdlowrey/auryn - da durfte ich bei Major-Upgrades Anpassungen vornehmen. Breaking Changes sind bei einem Major-Release völlig normal. Aber Breaking Changes bedeuten nicht, dass *zwangsläufig* Änderungen an deinem Code notwendig sind. Das hängt eben davon ab welche Teile einer Library du nutzt. Dass ein Twig seine render-Method in diesem Jahrhundert nicht mehr umbenennen wird, ist höchst wahrscheinlich.

                              Zitat von BlackScorp Beitrag anzeigen
                              Klar würdest du jetzt sagen "Wo ist das Problem, einfach rechtsklick, Find in Path.. und dann ersetzen". Nun, ich beschäftige mich seit 2009 mit PHP und es wenn es so einfach wäre, hätte ich es schon längst getan.
                              Da kann ich fast 10 Jahre drauflegen

                              Zitat von BlackScorp Beitrag anzeigen
                              Da machste auch nichts falsches daran, die Libs kann man wunderbar hinter Klassen verstecken und diese dann im DI ersetzen, wenn man gegen Interfaces programmiert. Beim Framework wirds schwieriger.
                              Man kann natürlich alles "weg-abstrahieren". Ich mache das aber nur, wenn die Verwendung einer Lib einen großen Impact auf meine Codebase hat. Das Routing bspw. passiert an einer sehr zentralen Stelle: das kann ich auch austauschen ohne es hinter ein eigene Interfaces zu stecken. Aber das ist Geschmackssache.

                              Zitat von BlackScorp Beitrag anzeigen
                              so ich werde nichts mehr zum Thema sagen, lotti wird sowieso das letze "aber" haben
                              hrhr

                              Kommentar

                              Lädt...
                              X