Le mkframework, découvrez un framework php très différent

Posté par (page perso) . Édité par ZeroHeure, palm123 et tankey. Modéré par patrick_g. Licence CC by-sa
Tags : aucun
5
7
mar.
2015
PHP

Il existe aujourd'hui beaucoup de frameworks php, mais un seul d'entre eux se différencie par sa rétrocompatibilité. Contrairement aux autres frameworks qui n'hésitent pas à changer de version en obligeant leurs utilisateurs à repasser sur l'ensemble des applications pour les "migrer" vers la nouvelle version, le mkframework, lui, est rétro compatible depuis sa publication en 2009

Il continue d'évoluer en restant compatible avec l'ensemble des applications l'utilisant depuis son lancement.

Ce framework est opensource, hebergé par le site developpez.com et proposé sous licence LGPLv3. Il est également disponible sur github et via composer

Une prise en main facilitée

Un générateur web

La courbe d'apprentissage des frameworks est souvent un frein à leur utilisation. Ici, grâce à un générateur web, vous pouvez en seulement quelques clics avoir une base utilisable pour votre application.

En effet le générateur web vous permet par exemple de

  • générérer la couche modèle
  • générer un module CRUD[1]
  • générer une gestion d'authentification
  • ajouter une gestion de droits à votre application

Des vidéos d'explication

Pour faciliter la prise en main, une vingtaine de vidéos montrent comment utiliser le framework.
Les utilisateurs peuvent également proposer des idées de vidéos.

De nombreux articles et tutoriaux

Vous pouvez retrouver des tutoriaux sur developpez.com, openclassrooms.com mais également dans le magazine papier PROGRAMMEZ.

Des tutoriaux plus ou moins complexes permettant aussi bien de découvrir le framework que de developper un réseau social, un twitter-like par exemple, et ceci très facilement.

Une gestion modulaire à sa création

Ce framework utilise des modules depuis 2009 quand d'autres les ont seulement implémenté depuis 1 ou 2 ans, en effet on peut imbriquer/moduler ses développements très facilement et ainsi capitaliser sur son travail. Quelques modules sont téléchargeables sur le site, permettant simplement d'utiliser Google Maps ou de générer des tableaux avec la librairie Guriddo, …

La sécurité au coeur du framework

Travaillant régulièrement avec des cabinets d'audits de sécurité, j'ai intégré les mesures conseillées par ces cabinets au framework au fil des années.
Il y a même une page consacrée sur le sujet: http://mkframework.com/security.html

Conclusion

L'essayer c'est l'adopter: même si la formule est un peu facile, la plupart des utilisateurs actuels reconnaissent que ce framework les a conquis dès le départ contrairement à d'autres qui leur paraissaient plus difficiles à prendre en main.

[1] tableau de listage + formulaires d'ajout/modification/suppression d'enregistrements

  • # Impossible

    Posté par (page perso) . Évalué à 10.

    mais un seul d'entre eux

    J'aimerais savoir comment on peut affirmer une chose pareil alors qu'il y a des centaines de bibliothèques !

    Ce framework utilise des modules depuis 2009

    J'utilisais déjà des modules avant 2000 en Perl. DBI existait bien avant ces daubes de fonctions mysql* du PHP !

    Parfois, je me demande vraiment pourquoi PHP a marché ;-)

    • [^] # Re: Impossible

      Posté par (page perso) . Évalué à 3.

      Pour la rétrocompatibilité, j'ai regardé l'ensemble des frameworks actifs, et aucun ne maintient sa version datant de 2009, tous ont fait des sauts de versions avec les cassage de compatibilité qui vont avec ;)

      Pour les modules php, je ne parle pas de l'équivalent de CPAN pour perl:

      Dans les frameworks, on travaille souvent avec le pattern MVC: on a ainsi des controllers, des vues et la couche modèle.

      Depuis la version 2 des frameworks les plus connu: Zend framework et Symfony, ils ont mis en avant une nouvelle chose: les "Bundles", avec enfin la possibilité de capitaliser sur ses développements.

      Le mk, depuis le début permet de capitaliser sur ses modules incluant controllers + vues, de plus, on pouvait dès le début facilement récupérer cette vue pour l'inclure ailleurs, chose simplifiée par la suite avec les "modules intégrables", permettant en plus de simplifier la navigation au sein de ce module intégrable ;)
      C'est de ça dont je parlais ;)

      Un framework php libre et facile à prendre en main : http://mkdevs.com

      • [^] # Re: Impossible

        Posté par (page perso) . Évalué à 5.

        Les systèmes de modules (avec leurs propres vues, contrôleurs et cie…) dans les frameworks, ça ne date pas de ZF, Sf ou même de mk. Jelix le fait depuis 2006 (qui est un fork de Copix qui le faisait déjà en 2004). Et possible qu'on puisse en trouver d'autres avant 2009…

        et puis un framework qui garde de la retrocompatibilité aussi longtemps que mkframework, ça me laisse songeur.

        • soit c'est un framework qui n'évolue pas (en terme d'API et d'organisation), et donc que son auteur n'évolue pas dans sa manière de coder ou ne tient pas compte des problèmes rapportés par ses utilisateurs (ne vient pas me dire que l'API parfaite existe)
        • soit c'est un framework qui est très minimaliste. Mais alors les utilisateurs auront tout de même des problèmes de rétrocompatibilités avec l'utilisation de lib externes. Et probablement aussi qu'ils n'utiliseront ce fmk que pour les petits projets.
        • soit c'est un framework qui maintient N version de la même API, mais cela veut dire très certainement de plus en plus de code mort à chaque nouvelle version (celui qui utilise une version d'une API, n'utilise pas les autres forcément). Et le code mort, c'est mal (contributions compliquées si pas bien documenté, code parsé pour rien par PHP, ou fichiers inutiles etc…).

        Il faut trouver un juste milieu quand on maintient une lib ou un framework. Les usages, les technologies, les besoins évoluent au fil du temps, et donc forcément, les APIs. Et il faut de temps en temps virer les vieux trucs, faire le ménage.

        Alors j'aimerais bien comprendre dans quel cas tu te situe parmi ceux que je viens d'évoquer, ou alors comment arrives-tu à garder cette rétrocompatibilité aussi longtemps ?

        Sur Jelix, j'ai fait des compromis :

        • les versions (1.0, 1.1, 1.2….) sont maintenues pendant 3 ans environ (aboutissant à des releases 1.0.1, 1.0.2 …) : uniquement des corrections de bugs et de trous de sécu. Mais pas de changements d'API (sauf si vraiment la correction d'un bug majeur l'oblige mais ça n'est pas arrivé en 9 ans ou je ne m'en souviens pas).
        • Une version peut faire évoluer une API. Déjà, très important, cette modification est documentée dans la documentation de migration (exemple), en plus des nouveautés (exemple). Si il s'agit de paramètres supplémentaires, j'essaye de faire en sorte que ce soit des paramètres optionnels. Ou alors je créé une nouvelle méthode ou classe et je marque l'ancienne "déprécié" quand cela reste pertinent. L'API dépréciée ne disparait du code source qu'au cours des futures version. Cela laisse le temps de migrer vers la nouvelle API.
        • Pour une version majeure (de 1.x à 2.x) : je me laisse la liberté de casser les API (c'est ce qui se passe pour la future 2.x, après 9 ans de dev sur la 1.x). Il faut savoir un jour faire table rase sur certains aspects, et arrêter de se trainer des boulets (qui n'en étaient pas forcément à l'époque où ils ont été développé). Un code "moderne", une API moderne, ça attire plus les utilisateurs (et les contributeurs). Et puis ça fait du bien pour les nouveaux projets.
        • [^] # Re: Impossible

          Posté par (page perso) . Évalué à 1.

          Autant pour moi pour les modules ;)
          On peut sur jelix avoir un module principal, par exemple l'accueil affichant deux sous modules, par exemple des CRUDs ?

          Pour la rétrocompatibilité, entre le point 1 et 2
          L'idée est simple: j'ai des applications qui furent développées au début du framework, vers 2009, et je peux mettre à jour le framework avec la dernière version sans casser mon application.

          Les mises à jour faites au fil des années:
          - suivi des suppressions de méthodes devenus obsolètes,
          - ajout de nouvelles fonctionnalités au fur et à mesure.

          Et en effet le framework est assi minimaliste, ce qui facilite aussi sa prise en main ;)

          Pour la question de la compatibilité avec les API "externes": on peut actuellement utiliser en complément des classes Symfony et Zend Framework versions 1 ET 2 ;)

          Donc cette "rétrocompatibilité" ne gènent pas les utilisateurs, et permet de ne pas demander sans cesse aux developpeurs de repasser sur leurs applications en production pour suivre les évolutions du framework.

          Un cas tout bête concret: une application développée il y a quelques années avec une version 1.* de Zend framework:
          Aujourd'hui
          - on ne peut pas la migrer sans passer de temps sur un nouveau serveur: les fonctions php utilisées (du framework) n'existent plus
          - on ne peut pas "juste" mettre à jour la version du framework: cassage de compatibilité totale, saut énorme pour rattraper la dernière version actuelle
          bilan l'application reste pour l'instant sur cette vieille version de serveurs, et il a été décidé de la re-developper le jour où l'on devra la migrer :(

          Donc les utilisateurs ont le choix : les frameworks suivant les tendances (namespaces…) au détriment de la rétro compatibilité il y en des masses: la quasi totalité.
          Personnellement j'ai fait un choix différent car ça m'embêtait de devoir repasser sur des applications qui tournent en production depuis des mois pour permettre d'être compatibile avec la dernière version du framework.
          C'est un choix: les utilisateurs ont le choix ;)

          Je trouve sympa de pouvoir dire à un utilisateur qui a commencé son application il y a 1 ou 2 ans: une nouvelle fonctionnalité est disponible pour toi: fais "juste" un update du framework, et à la rigueur d'un plugin (si c'est une fonctionnalité d'un plugin) et tu pourras en bénéficier.
          Plutot que: il y a de nouvelles fonctionnalités: met à jour le framework + suit la procédure de migration :(

          C'est un choix, je l'assume et mes utilisateurs actuels apprécient :)

          Un framework php libre et facile à prendre en main : http://mkdevs.com

          • [^] # Re: Impossible

            Posté par (page perso) . Évalué à 2.

            suivi des suppressions de méthodes devenus obsolètes

            Je ne comprends pas trop ce que tu veux dire là. Si tu supprimes, tu casses forcement la rétro-compatibilité. Si tu ne supprimes pas, tu te retrouves forcément avec du code mort.

            • [^] # Re: Impossible

              Posté par (page perso) . Évalué à 1.

              Par exemple, suite à l'obsolescence de "ereg_replace" je l'ai migré vers preg_replace
              Pas de cassage de compatibilité, et mise à jour pour les utilisateurs utilisant la version 5.3 de php ;)

              J'ai des applications datant du début du framework qui tourne sur la dernière version du framework
              J'ai également des applications qui ont pu migrer de serveurs au travers des années passant de php 5.2 à 5.3 sans difficulté ;)

              C'est un choix que j'ai fait et que j'assume, mes utilisateurs apprécient, sinon ils ont le choix d'aller voir d'autres frameworks :)

              Un framework php libre et facile à prendre en main : http://mkdevs.com

  • # Juste un hobby ?

    Posté par (page perso) . Évalué à 2.

    • Pas de tests
    • Commentaires en français
    • Un seul développeur
    • Herbergé sur developpez.com (!)
    • 2 bugs au total sur toute la vie du projet
    • < 300 commits depuis le debut (83 commits sur GitHub probablement parceque l'auteur n'a pas migre les commits de Subversion vers Git)

    Bref c'est un hobby, un jouet AMHA.

    • [^] # Re: Juste un hobby ?

      Posté par (page perso) . Évalué à 1.

      Pas de test ?

      si mais je ne les mets pas dans le svn et github ;)

      Pour info j'ai un svn privé et un svn public, sur mon svn privé j'ai au total 1639 commits.

      Commentaires en français

      Oui mes commentaires sont en francais, j'hesite à les convertir en effet ;)

      Herbergé sur developpez.com (!)

      Sur le svn de developpez.com et github pour git, pourquoi ?

      2 bugs au total sur toute la vie du projet

      ? non il y a eu beaucoup plus de bugs que ça, la plupart remonté soit via le forum, MP ou autre ;)

      Pour l'histoire de github/svn effectivement j'ai migré le projet également sur github très tard, je diffuse sur les deux plateformes ;)

      Un framework php libre et facile à prendre en main : http://mkdevs.com

      • [^] # Re: Juste un hobby ?

        Posté par (page perso) . Évalué à 0. Dernière modification le 10/03/15 à 02:09.

        si mais je ne les mets pas dans le svn et github […] j'ai un svn privé et un svn public, sur mon svn privé j'ai au total 1639 commits

        Ah, donc une partie seulement du code est open source en fait.
        Je suis curieux de connaitre ton workflow : tu fais plein de commits sur ton repo prive et une fois que le truc est stable, tu fais 1 commit sur le svn de developpez.com et 1 sur GitHub ?

        Sur le svn de developpez.com et github pour git, pourquoi ?

        Vue de loin, le svn de developpez.com ca fait pas tres pro, d'ou mon (!).
        Et quand on regarde d'un peu plus pres http://projets.developpez.com/projects, y'a une vingtaine de projets pratiquement tous morts et souvent meme pas nés, bref un cimetière.

        il y a eu beaucoup plus de bugs que ça, la plupart remonté soit via le forum, MP ou autre

        MP = message privé ? Ca commence à faire beaucoup de choses qu'on ne voit pas.

        • [^] # Re: Juste un hobby ?

          Posté par (page perso) . Évalué à 3.

          Je suis curieux de connaitre ton workflow : tu fais plein de commits sur ton repo prive et une fois que le truc est stable, tu fais 1 commit sur le svn de developpez.com et 1 sur GitHub ?

          Exactement: je commit sur le svn uniquement les mises à jour "stable"

          Vue de loin, le svn de developpez.com ca fait pas tres pro, d'ou mon (!).

          Si leur service est de qualité, on a un espace, avec un forum dédié, un bugtracker… tout ceci gratuitement ;)
          A l'époque (en 2009) je trouvais ce service sans égal ;)

          MP = message privé ? Ca commence à faire beaucoup de choses qu'on ne voit pas.

          Une partie des bugs sont rémontés dans le forum associé et une autre: on me post via MP des bugs que je corrige puis livre sur le svn avec commentaire explicatif.

          En cherchant sur les logs du svn on peut lire quand je corrige des bugs ;)

          Un framework php libre et facile à prendre en main : http://mkdevs.com

          • [^] # Re: Juste un hobby ?

            Posté par (page perso) . Évalué à 0.

            je commit sur le svn uniquement les mises à jour "stable"

            Mouai, ca tient donc plus du serveur ftp que du versioning. Tout ca m'a l'air d'être du bricolage.
            Je ne juge pas le contenu ni tes idees (qui sont peut être tres bonnes et interessantes a explorer), mais y'a certainement mieux comme organisation, ne serait-ce que pour donner une meilleure image du projet.

            Regarde comment est fait le travail sur les logiciels open source réputés (linuxfr.org par exemple, ou les frameworks AngularJS, Rails, Django…), ils sont beaucoup plus ouverts et leurs organisations sont tres éloignés de tes bidouilles.

            Je juge en revanche négativement le fait de parler d'un projet perso en 1er page de linuxfr alors qu'il manque clairement d'ouverture.

        • [^] # Re: Juste un hobby ?

          Posté par (page perso) . Évalué à 3.

          il y a eu beaucoup plus de bugs que ça, la plupart remonté soit via le forum, MP ou autre

          MP = message privé ? Ca commence à faire beaucoup de choses qu'on ne voit pas.

          Il n'est quand même pas responsable de la remontée des bugs par les utilisateurs. Linus aussi recevait des rapports de bugs par courriel au début.

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: Juste un hobby ?

            Posté par (page perso) . Évalué à 0.

            pas responsable de la remontée des bugs par les utilisateurs

            Bien sur que si. Quand t'as 2 bugs dans ton bug tracker c'est qu'il y a un soucis quelque part. Essaye de remonter des bugs via des mails privés sur des gros projets : on va te répondre de créer un ticket sur le bug tracker.

            • [^] # Re: Juste un hobby ?

              Posté par (page perso) . Évalué à 3. Dernière modification le 11/03/15 à 13:37.

              Mais ce n'est pas un gros projet justement. Et il y a une communauté active1 via le forum, qui trouve bon de remonter les bugs directement à l'auteur. Le but des remontées de bugs c'est de les faire corriger. Si l'auteur s'en sort comme ça c'est très bien. Il ne va quand même pas forcer l'emploi d'un bug tracker seulement pour éviter de se faire lyncher sur linuxfr.


              1. il y a 148 fils de discussion sur le forum depuis en gros, mars 2013, ils sont presque tous marqués "résolus" et visualisés plus d'une centaine de fois (plusieurs centaines pour les plus anciens). 

              "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

              • [^] # Re: Juste un hobby ?

                Posté par (page perso) . Évalué à -1.

                via le forum

                Je parle des "MP = message privé", "choses qu'on ne voit pas", "mails privés", pas des fils de discussion sur le forum qui sont par définition ouvert. Tant que les remontés de bugs/discussions se font de facon visible y'a pas de problème (bug tracker, forum, mailing-list…).

      • [^] # Re: Juste un hobby ?

        Posté par (page perso) . Évalué à 1.

        si mais je ne les mets pas dans le svn et github ;)

        Pourquoi ça ?? o_O

        Personne ne peut contribuer donc ?

        • [^] # Re: Juste un hobby ?

          Posté par (page perso) . Évalué à 4.

          On peut contribuer au framework comme ça a déjà été fait par le passé:
          - en discutant d'une évolution / bug
          - en proposant des modifications de code sur le forum
          - en faisant un pull request sur le github

          Le github a été choisi pour cela d'ailleurs, après je me débrouille pour synchroniser mes svn ;)

          Un framework php libre et facile à prendre en main : http://mkdevs.com

          • [^] # Re: Juste un hobby ?

            Posté par (page perso) . Évalué à 2.

            • en proposant des modifications de code sur le forum
            • en faisant un pull request sur le github

            À l'arrache donc. Car si les tests ne sont pas dans le dépôt, ça veut dire que le contributeur ne peut pas vérifier par lui même qu'il n'a pas cassé quelque chose. Et qu'il ne peut pas développer les tests qui vont tester sa nouvelle fonctionnalité ou sa correction de bugs. Et puis du coup ça te fais du boulot en plus (développer les tests).

            ;-)

            • [^] # Re: Juste un hobby ?

              Posté par (page perso) . Évalué à 3.

              Pourquoi "à l'arrache", pourquoi être aussi médisant ??

              Certaines personnes m'ont fournit la correction d'un morceau de code en préciseant le fichier et la ligne concerné
              J'ai ensuite regardé, verifié et testé ce code avant de l'implémenter

              Donc non je ne fais pas les choses à l'arrache.

              D'autant que j'ai pas mal de tests à faire pour eviter des cassages de compatibilité.

              Donc non je ne fais pas les choses à l'arrache: depuis 2009, je maintiens et continue d'améliorer ce framework en prenant en compte les retours, axes d'améliorations et corrections le plus sérieusement possible.

              Un framework php libre et facile à prendre en main : http://mkdevs.com

    • [^] # Re: Juste un hobby ?

      Posté par . Évalué à 3.

      Commentaires en français

      Et ? Quand tu te tapes des commentaires en anglais écrit par des français (donc : illisibles), t'es content d'avoir des commentaires en français.

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.