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 imikado . En réponse à la dépêche Le mkframework, découvrez un framework php très différent. É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