Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

FRamework/et/ou/template poiur application PHP

4 réponses
Avatar
ecante
Bonjour à tous,

J'ai réalisé une appli de gestion client/facture basée sur une base
MySql avec un modèle léger mais propre. Cependant la structure de mes
formulaires est vraiment trop lourde, je me sers de HTML/Quickform de
PEAR, mais les cas spécifiques m'ont fait doublé du code (et çà j'aime pas).
Je voudrais donc avoir des avis sur des framework ou des templates me
permettant d'alléger ces formulaires qui ne vont pas chercher loin. Ma
connaissance de Php est plutot correcte (je suis dev PHP), mais je n'ai
pas eu encore le teps d'approcher ces techno en fait.

Edz

4 réponses

Avatar
bruno
ton besoin se situe juste sur les formulaires?
doit tu faire du code JS de verification des entrées?

je croit savoir que quickform se charge tout seul du code JS...
attentino a ton choix, tu risque d'avoir pas mal de boulot au final...
Avatar
Francois Girault
Bonjour à tous,

J'ai réalisé une appli de gestion client/facture basée sur une base
MySql avec un modèle léger mais propre. Cependant la structure de mes
formulaires est vraiment trop lourde, je me sers de HTML/Quickform de
PEAR, mais les cas spécifiques m'ont fait doublé du code (et çà j'aime
pas).


Coupler son projet à des choix techniques a souvent ce genre de
dégénérescence où l'outil, sensé nous éviter une réinvention sauvage de
la roue, freine le reste. Faire des choix techniques induit presque
systématiquement un retour de baton si on n'audite pas suffisament le
produit à inclure. Prototypage et lecture du code (l'argument décisif
pour l'open-source! ;) ) garantissent la pérénité des choix, à mettre en
adéquation avec la criticité de l'application.

Je voudrais donc avoir des avis sur des framework ou des templates me
permettant d'alléger ces formulaires qui ne vont pas chercher loin. Ma
connaissance de Php est plutot correcte (je suis dev PHP), mais je n'ai
pas eu encore le teps d'approcher ces techno en fait.


C'est principalement le temps qui est l'ennemi du décideur et du testeur
(et de plein d'autres :) ). les frameworks font souvent des choses
complexes au prix d'une complexité architecturale qui fait que la prise
en main est souvent assez longue, car on rencontre des concepts fort
obscures si on en a jamais entendu parlé avant (non, je n'ai pas dit MVC
;) ). La prise de conscience d'une inadéquation au besoin alors que 50%
du budget du projet est déjà investi est ... fatale !

Donc, il faut tester, prendre, et parfois perdre, un temps fou à rentrer
dans la tête des concepteurs de framework, de lire les tutoriaux, les
documentations techniques, prototyper, comparer ...

C'est un reproche récurent fait à php que de ne pas (encore) avoir un
framework de référence, un modèle de composants solide et intelligible
de facto. (pas de troll sur php vs java)

Cependant, divers projets existent, avec leurs qualités et défauts.

Prado : http://www.xisc.com/

Mojavi : http://www.mojavi.org/

et d'autres que google connais mieux que moi ;)

Et des nouvelles neuves sur les spéculations marketoïdes de zend et ibm :

http://www.procata.com/blog/archives/2005/10/18/zend-php-framework-not-a-rumor/

Dans l'état actuel de php, mon parti-pris est d'intégrer (ou de créer)
des "petits" composants sur lesquels je suis capable d'intervenir sur le
code au cas où, et de les assembler dans une structure la plus découplée
possible, pour éventuellement changer un morceau pour un autre en
minimisant la casse ...

FG

Avatar
ftc

Donc, il faut tester, prendre, et parfois perdre, un temps fou à rentrer
dans la tête des concepteurs de framework, de lire les tutoriaux, les
documentations techniques, prototyper, comparer ...


C'est un reproche récurent fait à php que de ne pas (encore) avoir un
framework de référence, un modèle de composants solide et intelligible
de facto. (pas de troll sur php vs java)


C'est pour ces raisons qu'il ne faut pas choisir le framework (
bibliothèque, bout de code ... ) qui correspond le mieux aux besoins,
mais celui qui sera le plus facilement adaptable aux besoinx.

C'est vrai que des composants comme HTML_QuickForm paraissent très bien
au premier abord mais on se rend vite compte que si celui-ci ne
correspond pas vraiment aux besoins, il sera difficle de l'adapter (
j'entend par difficile qu'il faudra un temps non négligeable pour le
mettre e conformité aux spécifications du développement ).

Pour ce qui est des formulaire, j'ai trouvé deux composants récemment
qui paraissent facilement modifiables ( je dit paraissent car je ne les
ai pas testé, j'ai juste parcouru leur code vite fait ):

FP_Form : http://www.filepocket.org/rack/fp_Form/
et
Form Builder : http://www.rodesia.org/?section=FormBuilder



Cependant, divers projets existent, avec leurs qualités et défauts.

Prado : http://www.xisc.com/

Mojavi : http://www.mojavi.org/

et d'autres que google connais mieux que moi ;)


j'en citerais deux autres :

Copix (www.copix.org) réalisé par la société Aston
et CakePHP (www.cakephp.org) qui est un framework inspiré de Ruby On Rails

Avatar
oscarima
N'oublions pas Castor, développé par la société 2le.Net (castor.2le.net).

Le sujet est toujours le même, il peut être quelques fois plus rapide de
produire et donc de gérer ces propres outils ou son propre framework.

Même en développant sur le même framework et en étant contributeur, il
arrive que l'on perde du temps sur des fonctionnalités développées par
autrui. L'ennemi du framework, c'est le temps que l'on n'a pas toujours
malheureusent. (faut bien vivre et donc sortir les projets rapidement)