Tandis que la concurrence (ZF, Symfony, etc.) s'applique généralement à fournir un cadre applicatif extrêmement riche en fonctionnalités diverses et variées, Sloth se focalise exclusivement sur la partie Vue et la partie Contrôleur du pattern Modele-Vue-Controleur en suivant au maximum le KISS-principe.
L'innovation majeure de Sloth comparée aux autres framework MVC réside dans son implémentation de la partie Vue. Celle-ci repose en effet sur l'utilisation de classes Document_Object_Model encapsulées dans une API publique très proche de celle de jQuery.
Les priorités du projet sont maintenant la traduction du manuel en anglais, l'optimisation et une couverture complète du code en terme de tests unitaires. Toute aide est bien sûr bienvenue :) Traitement des requêtes/réponses orienté objet
PHP est un excellent langage, toutefois, le poids de l'âge fait que la gestion des requêtes et des réponses est toujours très procédurale ; ce qui peut poser problème dans le cas de gros projets. D'autre part, il n'y a pas de moyen simple pour générer des URL jolies à travers toute une application.
C'est pourquoi Sloth propose une méthode de traitement des requêtes complètement orienté objet et conçu de manière à obtenir de belles URL simplement.
jQuery en PHP ?
Le document XML est exploité sous forme d'un arbre DOM. Toutefois, en raison de son caractère générique, la spécification du W3C est très peu pratique dans le cadre du développement web. C'est pourquoi le framework impose une encapsulation des DOMElement et DOMNodeList dans la classe Sloth_DOM.
L'API de cette classe est quasiment compatible à 100% avec celle de jQuery (bibliothèque Javascript).
Aller plus loin
- Page d'accueil (83 clics)
- Release 0.2 (14 clics)
- Launchpad du projet (21 clics)
# Pffff! PHP ca vit encore ? Ah oui, encore quelques sursauts ....
Posté par totof2000 . Évalué à -8.
[^] # Re: Pffff! PHP ca vit encore ? Ah oui, encore quelques sursauts ....
Posté par nanard . Évalué à 5.
Allez tous vous faire spéculer.
[^] # Re: Pffff! PHP ca vit encore ? Ah oui, encore quelques sursauts ....
Posté par Nicolas Blanco (site web personnel) . Évalué à 2.
[^] # Re: Pffff! PHP ca vit encore ? Ah oui, encore quelques sursauts ....
Posté par totof2000 . Évalué à 6.
# Symfony
Posté par rewind (Mastodon) . Évalué à 4.
Symfony aussi. Symfony intègre des ORM extérieurs (Doctrine et Propel, au choix).
# Yapf ...
Posté par Benjamin (site web personnel) . Évalué à 10.
Yet Another Php Framework ;)
C'est précisément ce dont se plaignaient les auteurs de php (et du Zend Framework), et je trouve qu'ils ont bien raison sur ce point.
Les paradigmes développés par chaque framework sont sûrement très intéressants ...
Mais pourquoi diantre faut-il 42 frameworks en PHP ?
Donc 30 de non maintenus, et aussi 18 d'infiniment compliqués ? (cake/symfony) et 22 qui multiplient en moyenne par 8 la consommation de CPU par page, et 20 qui multiplient par 7 la consommation moyenne de RAM par page (utilisez Java 1.4 dans ce cas les gars hein ;) )
J'en ai longtemps douté, mais c'est finalement peut-être sa facilité d'utilisation et de développement qui risque vraiment de perdre PHP : trop de diversité médiocre (je ne dit pas que Sloth l'est, mais est-il nécessaire ? pourquoi ne pas juste apporter les paradigmes inventés par leurs auteurs dans Zend par exemple ...)
C'est toutes ces raisons qui m'ont fait choisir Zend et aussi les dernières :
- une doc d'API parfaite (doc brute type phpdoc, complète et requise pour entrer dans le framework et doc utilisateur avec des phrases et des exemples, des use cases et la façon dont les auteurs utilisent la ou les classes décrites...)
- un framework 'relativement léger' pour éviter de transformer l'avantage de PHP en un inconvénient
- un suivi de projet très serré : n'importe quoi ne rentre pas dans ce Framework, et les raisons écrites (code bien écrit, bonne intégration dans l'existant, doc exhaustive etc.) suffisent bien souvent pour bloquer l'entrée de trucs dangereusement écrits ...
- le point précédent n'empêche pas pour autant qu'il reste facilement extensible (façon Java...) on a par exemple développé nos propres classes et notre propre générateur autour de Zend très facilement ...
[^] # Re: Yapf ...
Posté par Sébastien Le Ray . Évalué à 6.
Et contrairement à pas mal de frameworks qui veulent faire les beaux, ils n'ont pas pris le parti d'utiliser forcément une conf XML en 3000 fichiers (oui, désolé de vous le dire les gentils lutins développeurs PHP mais votre langage préféré ne disposant pas de serveur d'application, le parsing des fichiers XML est à refaire à chaque requête)...
Le seul reproche que je ferai à Zend c'est qu'ils fournissent des éléments très indépendants bien faits mais c'est aux développeur de faire la "glue" entre tout ça (notamment entre modèles, vues et contrôleur), c'est pour ça que le mieux est de développer un squelette d'application maison qui vient par dessus Zend Framework et est repris à chaque nouveau projet (nous on s'est posé comme règle de ne jamais utiliser les classes ZF directement mais d'avoir toujours des classes maison qui fassent tampon entre les deux).
[^] # Re: Yapf ...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
C'est pas parce que des frameworks utilisent XML pour certaines choses, qu'ils lisent les lisent à chaque requête. Jelix par exemple traduisent ces fichiers en classe PHP, à la volée, et mis dans des fichiers de caches. Tu vas me dire, pourquoi du XML alors ?
* avec xml, on est plus dans un processus déclaratif que programmatif : on peut donc définir certaines choses plus simplement, plus intuitivement (et derrière le PHP généré peut être complexe à souhait, c'est pas un problème)
* avec des fichiers XML : ça peut être généré et retravaillé facilement par des outils tiers. Ex, un fichier de déclaration de formulaire en XML : on peut avoir un plugin dans eclipse pour générer et modifier un formulaire en quelques cliques de souris. Va donc faire un outil qui arrive à modifier du PHP sans tout casser (même avec une API de reflexion...)
* certains se plaignent que le XML, c'est chiant à éditer à la main : à ceux là, je leur dis qu'il y a pléthore d'éditeur XML qui facilite l'édition de ces fichiers, pour peux que l'on fournisse les schemas. Et dans Jelix, on les fournis (en RelaxNG).
Bref, faut arrêter avec le XML bla bla c'est lourd bla bla c'est verbeux. Si on utilise les outils qui vont bien, et si le framework utilise le XML d'une manière intelligente, il n'y a aucun soucis.
Et puis, il faut pas oublier que créer une appli web, c'est généré du contenu XML (XHTML) ou SGML...
[^] # Re: Yapf ...
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
> ceux là, je leur dis qu'il y a pléthore d'éditeur XML
Je suis de ceux la mais dans un autre journal, j'avais posé la question de ces éditeurs, sans réponse vraiment claire et satisfaisante.
Donc, je la repose ici. Existe-t-il un éditeur XML libre correct ? Y-a-t-il un editeur XML correct qui fonctionne dans un terminal (sans X) ?
J'avoue que tant qu'il n'y aura pas cela de base dans ma distribution préférée, j'aurais un mal fou vraiment aimer le XML pour les fichiers de configuration.
[^] # Re: Yapf ...
Posté par Raphaël G. (site web personnel) . Évalué à 2.
Personnellement je l'utilise comme ceci :
:%s%>\(\s\|\r\|\n\)*<%>\r<%g
ggVG=
La première nettoie tout les espaces qu'il y a entre les tags ><, la seconde va indenter ton fichier xml comme il faut avec des vrais tab...
Après un peu de changement dans ton .vimrc pour réduire a 4 espace la largeur d'une tabulation et ça roule ;)
[^] # Re: Yapf ...
Posté par Damien ARISTODEMO (site web personnel) . Évalué à 7.
C'est le même genre de reproche qu'on entend de temps à autre pour Gnu Linux: pourquoi tant de distribution, mais je ne vois pas en quoi ça gène réellement, dans la mesure ou ça n'empêche en rien Cake, Symphony ou Zend d'exister.
Il y a juste beaucoup de framework parce que beaucoup de gens utilisent php, que c'est du libre, et qu'ils sont simple à développer ( un petit php/mysql et ça roule.
Enfin, moi je ne me plaint pas de pouvoir choisir parmi une foule de fw php, ni parmi une foule de navigateurs web, ni de ceci ou de cela, etc.. Si tu veux limiter tes choix aux "gros" trucs ( allez par exemple debian/ Zend/firefox ou d'ailleurs même pourquoi pas XP/.Net/IE7 ), à tord ou à raison peu importe, libre à toi, et l'existence du nouveau Sloth qui de son côté satisfera sans doute beaucoup de gens, n'entravera pas ton choix.
Enfin.. juste mon avis.
# php
Posté par Julien . Évalué à -2.
Je ne parle pas de la maintenabilité de la plupart des sites PHP .. avec du bon gros code imbriqué dans de l'HTML, un pur plaisir.
OK c'était pratique dans le temps pour faire des petits sites pour des neuneus qui n'y connaissent rien en programmation ... mais bon.
[^] # Re: php
Posté par jeffcom . Évalué à 9.
Je ne parle pas de la maintenabilité de la plupart des sites PHP .. avec du bon gros code imbriqué dans de l'HTML, un pur plaisir.
ça n'a rien à voir avec php, désolé... ce n'est pas parce que php permet ça qu'il faut le faire... et ce n'est pas parce que certains devs n'ont rien compris que tous n'ont rien compris...
De même que tout ce que tu cites (qui est vrai par ailleurs) il convient au dev de coder proprement en tenant compte de tout cela et c'est très possible de faire un code très propre et léger en php, je t'assures
Et puis franchement des codes illisibles à la syntaxe immonde on en trouve aussi en python (oui c'est possible de faire le porc en py aussi) et je ne trouve pas que la syntaxe de ruby pique moins les yeux... et soit beaucoup plus intuitive... bref, quel que soit le langage on peut soit faire quelque chose de léger ou quelque chose de lourd, tout dépend du talent du dev
(et zut j'ai marché dedans)
[^] # Re: php
Posté par windu.2b . Évalué à 5.
Mais force est de reconnaitre que pour certains choix, on se demande franchement qui a eu cette idée !
Exemple connu de tous les développeurs PHP : le register_globals[1]...
Certes, cela rend le code plus rapide à écrire, mais au détriment évident de la sécurité du site.
Et malheureusement, si on permet certaines libertés d'écriture du code, il ne faut pas s'étonner que certains (mauvais) développeurs en tirent parti. "Si PHP le permet, c'est bien pour que je m'en serve, non ?"
1 Pour ceux qui ne connaissent pas, sachez qu'il s'agit d'un paramétrage qui permet, ou non, d'accéder à une variable quelque soit son emplacement. Donc "$var" pourra tout aussi bien désigner une variable créée dans le code, qu'une variable passée en paramètre d'URL ! Je vous laisse imaginer la faille de sécurité...
Ce paramètre était par défaut à "on" jusqu'à PHP 4 inclus. Ce n'est que sous PHP5 que le paramétrage est passé à "off" (avec tout de même la possibilité de le remettre à "on" en cas d'incompatibilité avec les anciens scripts mal codés).
[^] # Re: php
Posté par sov36 . Évalué à 4.
[^] # Re: php
Posté par jeffcom . Évalué à 8.
Exemple connu de tous les développeurs PHP : le register_globals[1]...
ça viens de la version "presque2" (PHP+FI) de php (du temps où ça s'appelait encore Personal Home Page, vers 1995) qui était un mix entre le php1 (quelques binaires visant à remplacer des routines récurrentes en perl) et FI (Form Interpreter) qui était un autre projet de Ledorf (créateur de la première mouture) qui était destiné à traiter des formulaires. à l'époque c'était très "simple" comme code, et ça simplifiait beaucoup les choses (et ça paraissait naturel) d'avoir les variables déjà disponibles, et puis php ne faisait pas autant de choses que maintenant. c'est dans la version 2 que l'option est apparue et qu'on a eu des tableaux globaux en plus des variables brutes.
C'est resté en php3 simplement parce que les 2 gus (Zeev Suraski et Andi Gutsman) qui ont repris le projet, nettoyé et réécrit le code et créé le parser qu'on connaît aujourd'hui (zend) n'ont pas voulu tout chambouler à ce stade là.
Lorsque php4 est sorti, beaucoup de scripts étaient en php3, on a gardé la directive, le problème c'est que de mauvais dev (ou des noobs¹ ignorant ce que ça peut générer comme merde) ont continué à diffuser/utiliser des scripts necessitant register_globals à "on" mais en utilisant des fonctionnalités propres à php4 d'où le fait qu'en php5 on a encore cette directive dans php.ini... pour la rétro-compatibilité
Voilà pour les fautifs.
¹ c'est pas péjoratif, on a tous été noob un jour... et on a tous un code bien crado qui traîne au fond d'un vieux HDD ou sur une disquette, oui oui faites pas les saints, on est tous passé par là
# KISS ? C'est une blague ?
Posté par srm . Évalué à 0.
C'est une blague ou je n'ai rien compris.
J'ai regardé la doc, car je me suis dit que ça devait être un Framework très intéressant si il suivait le KISS-principe.
Et bien je ne trouve pas du tout que ça soit le cas, je le trouve lourd et pas pratique pour un sous.
Je suis utilisateur de Archlinux pour information.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.