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
Aller plus loin
- Mkframework (720 clics)
- Page sur la sécurité (89 clics)
- Vidéos (135 clics)
# Impossible
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
J'aimerais savoir comment on peut affirmer une chose pareil alors qu'il y a des centaines de bibliothèques !
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 imikado (site web personnel) . É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 Laurent J (site web personnel, Mastodon) . É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.
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 :
[^] # Re: Impossible
Posté par imikado (site web personnel) . É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 Laurent J (site web personnel, Mastodon) . Évalué à 2.
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 imikado (site web personnel) . É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 tanguy_k (site web personnel) . Évalué à 2.
Bref c'est un hobby, un jouet AMHA.
[^] # Re: Juste un hobby ?
Posté par imikado (site web personnel) . Évalué à 1.
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.
Oui mes commentaires sont en francais, j'hesite à les convertir en effet ;)
Sur le svn de developpez.com et github pour git, pourquoi ?
? 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 tanguy_k (site web personnel) . Évalué à 0. Dernière modification le 10 mars 2015 à 02:09.
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 ?
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.
MP = message privé ? Ca commence à faire beaucoup de choses qu'on ne voit pas.
[^] # Re: Juste un hobby ?
Posté par imikado (site web personnel) . Évalué à 3.
Exactement: je commit sur le svn uniquement les mises à jour "stable"
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 ;)
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 tanguy_k (site web personnel) . Évalué à 0.
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 ZeroHeure (site web personnel) . Évalué à 3.
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 tanguy_k (site web personnel) . Évalué à 0.
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 ZeroHeure (site web personnel) . Évalué à 3. Dernière modification le 11 mars 2015 à 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.
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 tanguy_k (site web personnel) . Évalué à -1.
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 imikado (site web personnel) . Évalué à 2.
Les 3: Mails privés, Messages privés + messages sur le forum
Y a de tout, beaucoup passent par le forum mais pas tous ;)
En tout cas je suis transparent dans mes messages de commit svn ;)
Pour rappel: http://projets.developpez.com/projects/mkframework/repository
Un framework php libre et facile à prendre en main : http://mkdevs.com
[^] # Re: Juste un hobby ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 1.
Pourquoi ça ?? o_O
Personne ne peut contribuer donc ?
[^] # Re: Juste un hobby ?
Posté par imikado (site web personnel) . É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 Laurent J (site web personnel, Mastodon) . Évalué à 2.
À 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 imikado (site web personnel) . É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 xcomcmdr . Évalué à 3.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.