Jelix est un framework opensource pour PHP 5.1, qui comporte de nombreux composants et repose sur des modèles connus comme MVC, DAO, etc, tout en restant léger et performant. La version 1.0 beta 3 qui vient de sortir apporte des nouveautés importantes :
* un système de formulaire qui permet de gérer automatiquement les erreurs, la validation aussi bien côté client que coté serveur, ainsi que la génération automatique du code HTML et javascript. Tout ceci à partir d'un simple fichier descriptif en XML. ( http://jelix.org/articles/manuel/jforms )
* un contrôleur générique pour faire de la gestion de données très rapidement (type CRUD) ( http://jelix.org/articles/tutoriels/principal/crud )
* un module pour faire des tests unitaires aisément
* une uniformisation dans l'organisation des divers types de plugins
* de nombreuses améliorations dans la plupart des composants du framework.
Et bien sûr, comme dans les versions précédentes, Jelix 1.0 beta 3 propose une architecture modulaire, un moteur de template performant, des composants pour gérer l'authentification, les droits, l'internationalisation, ou encore faire du mapping relationnel-objet et de la communication inter-module. Le framework peut prendre aussi en charge les urls significatives, les thèmes, l'UTF-8, XML-RPC, JSON, RESTFull et bien d'autres choses. Sans oublier des scripts en ligne de commande qui permettent de développer rapidement.
À noter aussi les améliorations sur le site et les gros efforts qui ont été fait sur la documentation. Enfin l'ouverture d'une forge pour les développeurs de modules, plugins, et outils pour Jelix, qui comporte notamment un projet de plugin pour Eclipse, jelixeclipse, facilitant le développement d'applications pour Jelix.
Jelix 1.0 beta 3 est utilisé sur plusieurs sites, dont un à très forte audience (l'une des plus grosses plateformes de blog en France), et de ce fait peut être considéré comme stable. C'est d'ailleurs la dernière beta avant la version 1.0.
Jelix est disponible en deux éditions : l'édition "developer" pour la phase développement d'une application, et l'édition "optimized" (facultative), optimisée pour les serveurs en productions.
Site web : http://jelix.org
Téléchargement : http://jelix.org/articles/telechargement/stable
Liste détaillée des changements : http://jelix.org/articles/changelog/1.0beta3
La forge : http://forge.jelix.org
Journal Jelix 1.0 beta 3
18
sept.
2007
# Jelix template standalone utilisé sur PEM
Posté par Pierrick Le Gall (site web personnel) . Évalué à 3.
J'envisage à terme d'utiliser davantage le framework Jelix pour l'ensemble de l'application.
Longue vie au projet :-)
[1] https://gna.org/projects/pem/
[^] # Re: Jelix template standalone utilisé sur PEM
Posté par Philippe M (site web personnel) . Évalué à 2.
J'ai fais le tour des framework php pour un projet au taf, et Jelix m'a semblé le plus aboutie des projets français. Malheureusement c'est encore un peu obscur pour moi ces histoires de framework.
Born to Kill EndUser !
# Documentation
Posté par Ymage . Évalué à 3.
Désolé mais je reste adepte du format papier (livre ou PDF imprimé) à lire au calme et je pense que ça peut freiner l'adoption de ne pas proposer un support de ce type ...
Voilà, voilà, c'était pour dire rien du tout ...
Si vous n'aimez pas ce commentaire c'est qu'il est ironique.
[^] # Re: Documentation
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Mais je note ta requête :-)
[^] # Re: Documentation
Posté par BAud (site web personnel) . Évalué à 3.
J'avais regardé cela avec un contributeur sur http://faq.eagle-usb.org/wakka.php?wiki=DocFaqEagleFr avec une intro au Docbook sur http://faq.eagle-usb.org/wakka.php?wiki=DocBook
et les dévs effectués : http://faq.eagle-usb.org/wakka.php?wiki=DevFaqEagleFr (oula en 2003 déjà /o\).
Sans doute que côté wikipedia leur projet de création d'encyclopédie papier a avancé, mais je n'ai pas forcément bien suivi.
[^] # Re: Documentation
Posté par ethtezahl . Évalué à 1.
Oui, ce serait sympa une documentation offline.
Et puis, ça permettrait sûrement de développer un module spécialement conçu pour le PDF en plus :-) (Le tout extrait d'une base, j'en salive déja)
# Quel avantage par rapport à symfony ?
Posté par Nicolas (site web personnel) . Évalué à 3.
Mais en découvrant symfony et le tutoriel askeet, les premiers abords sont nettement facilités. J'ai développé pour le moment un unique site avec symfony. Peux-tu me donner (ou me donner une url) des arguments qui me feraient adopter jelix plutôt que symfony ? Ou tout au moins qui m'inciteraient à découvrir ton framework plus en profondeur ?
Ce que j'apprécie particulièrement dans symfony, c'est sa modularité. Il utilise propel comme orm mais si on préfère doctrine (ou autre chose), c'est facile de changer. Il utilise php comme moteur de templates mais si on préfère smarty c'est encore facile de changer,...
[^] # Re: Quel avantage par rapport à symfony ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Cependant, il y a quelques points que j'ai regardé, et sur lequel je pense que Jelix est supérieur. Par exemple, propel ou doctrine c'est bien, mais ce sont des trucs énormes, voir bloatware. En effet, les trucs à la activeRecord "redécouvrent" à chaque requête http le schema d'une table ou d'une base de donnée et inclus donc tout un mécanisme pour générer entièrement les requêtes SQL dynamiquement, à chaque fois qu'il faut faire une requête SQL. (bien que les implémentations tentent de mettre des systèmes de cache un peu partout dans leur code, mais c'est à mon sens plus des bouts de scotch qu'autre chose).
Ça a un intérêt en développement, c'est même sexy à utiliser, mais c'est, pour moi, un truc complètement contre productif dans un environnement en production, une fois que le site est en ligne, dans la mesure où à partir de ce moment là, les schemas des tables ne bougent plus. Partant du constat que la façon la plus performante de faire des requêtes est de les écrire en dur dans le code (ou quasi en dur, puisque généralement on a des paramètres), jDao a été crée en ce sens, tout en évitant au développeur d'écrire des trucs rébarbatifs, voir même du code non sécurisé (puisque jDao génère du code qui est tient compte des problèmatique de SQL injection). À partir d'un fichier qui décrit le mapping (fichier qui peut être généré par une ligne de commande), jDao, à la première execution, génère une classe une bonne fois pour toute, avec des requêtes en dur dans le code de cette classe, comme si tu avais fait toi même la classe métier et écris toi même les requêtes. jDao est ainsi plus léger et permet au framework de ne pas avoir à "redécouvrir" à chaque execution de page la structure d'un enregistrement ou autre. À noter cependant que jDao n'est peut être pas encore aussi puissant que doctrine ou propel, mais je pense de toute façon que son principe de fonctionnement est plus interressant au niveau des performances.
Et j'ai essayé d'avoir la même philosophie dans les autres composants de Jelix : tout est fait dans jelix pour que l'application soit performante, et pour éviter autant que possible, d'une part d'avoir des traitements qui sont inutiles dans un context de production comme je viens de l'expliquer, et d'autre part d'avoir du code mort (des trucs jamais utilisé par l'applis mais toujours chargé), y compris du code qui serait propre à une version de PHP (donc qui serait "mort" pour d'autres versions de PHP): tu peux te construire un framework jelix optimisé pour ta version de PHP, tu as même une édition "GOLD" qui inclus une extension PHP à installer sur le serveur, et qui prend en charge certains traitements de PHP, accélérant donc le fonctionnement.
Et je rajouterai que ce n'est pas par hasard si Jelix a été choisi par les développeurs de la plateforme over-blog, sur laquelle plus de 5 millions de pages sont lues par jour (et même plus, ce chiffre est vieux), et hébergeant plus de 630 000 blogs.
Bon après, en dehors des considérations sur la performance, un framework se juge sur les possibilités qu'il offre par rapport à ses propres besoins dans ses projets (il y a aussi une part de "feeling", vis à vis de la manière dont on créer une application avec tel ou tel framework). Et ça, il n'y a que toi qui puisse faire la part des choses, et donc, plutôt que de lire mon argumentation qui pourrait de toute manière toujours être prise comme totalement partiale et subjective :-), le mieux est que tu ailles voir un peu les quelques tutoriaux pour te faire une idée du truc.
[^] # Re: Quel avantage par rapport à symfony ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 1.
pardon, il faut lire "certains traitements de Jelix"
[^] # Re: Quel avantage par rapport à symfony ?
Posté par Moogle . Évalué à 2.
C'est peut être pas réalisé exactement de la même façon, mais dans Symfony (enfin, dans Propel), des classes fixes sont aussi générées à partir du schéma, donc non, le schéma de la table n'est pas redécouvert à chaque chargement de page.
[^] # Re: Quel avantage par rapport à symfony ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
* On peut déclarer dans le fichier XML des méthodes et indiquer les critères de ce qu'elles devront récupérer, effacer ou mettre à jour. Cela évite de devoir générer la requête à coup d'objet Criteria comme dans Propel : les requêtes sont donc en dur dans la classe générée.
* jDao suit le design pattern DAO
* Un objet DAO peut être mappé sur plus d'une table
* Pas de génération explicite des classes : dés qu'on modifie le fichier XML, les classes sont regénérées (on peut désactivé cette vérification de mise à jour en prod).
* Un fichier XML par objet mappé, et non pas tout dans un seul fichier. Chaque module contient donc ses propres fichiers XML jDao. Cela facilite l'installation de modules tiers. (peut être qu'il est possible d'avoir plusieurs fichiers avec Propel, mais j'ai pas vu)
Enfin jDao est plus léger que Propel (6 fichiers/81ko, contre 74 fichiers/681ko pour propel), même si il est vrai qu'il a un peu moins de fonctionnalités. Mais ce qu'il permet de faire couvre déjà pas mal des besoins AMHA. Et des améliorations sont prévues dans les versions à venir.
[^] # Re: Quel avantage par rapport à symfony ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
pardon, cela ne concerne que le générateur de Propel. Il faut donc y ajouter les 37 fichiers/246ko du runtime :-) (parmis les 6 fichiers de jDao, il y a le runtime et le générateur)
[^] # Re: Quel avantage par rapport à symfony ?
Posté par Nicolas (site web personnel) . Évalué à 1.
> * Pas de génération explicite des classes : dés qu'on modifie le fichier XML, les classes sont regénérées (on peut désactivé cette vérification de mise à jour en prod).
Tu veux dire que les classes sont reconstruites automatiquement dès qu'on modifie le schéma ? Même si c'est désactivable, je trouve ça génant dès qu'on travaille à plusieurs.
> * Un fichier XML par objet mappé, et non pas tout dans un seul fichier. Chaque module contient donc ses propres fichiers XML jDao. Cela facilite l'installation de modules tiers. (peut être qu'il est possible d'avoir plusieurs fichiers avec Propel, mais j'ai pas vu)
On peut évidemment faire plusieurs schémas!
Ton dernier argument sur la taille n'est pas un critère pour moi.
[^] # Re: Quel avantage par rapport à symfony ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
oui
> Même si c'est désactivable, je trouve ça génant dès qu'on travaille à plusieurs.
Je ne vois pas en quoi c'est génant. jDao et en particulier CopixDao (vu la jeunesse de Jelix :-) ), a été utilisé sur de nombreux projets de plusieurs développeurs depuis des années, ça n'a jamais posé de souci.
>Ton dernier argument sur la taille n'est pas un critère pour moi.
Et pourtant, c'est un argument important. Vu que PHP reparse les sources à chaque requête HTTP, ça fait une grosse différente au niveau tenue du serveur en charge. Si tu utilises un cache d'opcode (APC), la différence sera moindre, mais il y en aura quand même une : la quantité de mémoire nécessaire pour stocker l'opcode (plus le programme est gros, plus il prend de la mémoire dans sa version compilé, logique..). Et même si l'utilisation du framework est déstiné à un site à faible trafic, cela peut aussi faire une différence en hébergement mutualisé.
[^] # Re: Quel avantage par rapport à symfony ?
Posté par Nicolas (site web personnel) . Évalué à 1.
Je vais tâcher de trouver un moment pour regarder comment fonctionne jelix.
# Un petit peu d'humour...
Posté par Nicolas Blanco (site web personnel) . Évalué à -3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.