Discussion :

[jsebfranck]

Bonjour à tous,

J'aimerai créer une application web et j'en suis encore au choix de la techno, j'hésite entre jsf et php. Une rapidité de temps de réponse est un critère TRES important pour ce projet. A noter que je débute en jsf.

Est ce que php est plus rapide? ou est ce équivalent?

Je me doute bien que cela dépend également de la qualité du développement de l'application. Est-il donc difficile de développer une application performante en JSF? Et quelles sont selon vous les règles d'or à suivre pour obtenir les meilleurs temps de réponse?

Merci d'avance pour vos lumières,

[jsebfranck]

Personne n'a d'avis sur la question?

[seddik_saber]

peut etre que c'est difficile d'avoir quelqu'un travaillant avec php et JEE en meme temps et a assez de recul pour avoir un avis objectif

[jsebfranck]

Qu'en est-t'il alors pour les questions suivantes :

Est-il donc difficile de développer une application performante en JSF?

Quelles sont selon vous les règles d'or à suivre pour obtenir les meilleurs temps de réponse?

[seddik_saber]

1 ère question:
non mais il faux bien définir le périmètre de besoin avant de commencer, pour choisir les technologies nécessaire l'implémentation,la bibliothèque de composants , templating....etc
2eme question
je peux pas t'y répondre exhaustivement (pas eu a faire un dev ou le temps de réponse est primordiale) mais je peux dire comme toute application java ne fais pas un traitement ou requête d'info dans ta request que tu on pas besoin dans ton affichage.

[scanlan]

Et voila une autre moitié de réponse :
En ce qui me concerne je n'ai jamais utilisé PHP, mais je mange du JSF depuis plus d'un an et je trouve ça quand même bien lourdingue. L'écriture des pages est relativement simple, tant que l'on n'a pas de besoins qui sortent des pools de composants existants, ou que l'on se trouve pas confronté à certaines bizarreries. Mais comme c'est souvent le cas, je me retrouve à m'enliser dans mes bidouilles javascript/jsf/ajax et je suis quasiment sûr que j'irais plus vite avec un bête framework comme struts. Sinon question performances, ben c'est pas la joie je trouve. Dès que tu manipules des tableaux relativement importants, ça rame méchamment.
Donc à mon avis, JSF c'est pas la panacée à moins d'être lié à de fortes contraintes Java (EJB, JMS etc). Quant à savoir si on retrouve ce genre de problèmes sur tous les frameworks web, aucune idée

[sir_gcc]

Moi aussi je fais du dév d'appli web avec JSF, et je trouve que ça n'est pas si lent que ça. Surtout compte tenu de la qualité d'une appli web JSF. Je veux dire par là que le java pour le web, c'est sur, ça n'a pas beaucoup d'interêt pour un site perso ou un petit site d'entreprise isolé (c'est le site qui est isolé). Par contre dès qu'on se trouve dans une grosse structure, avec plusieurs applications qui ont des besoins différents mais doivent pouvoir utiliser des ressources communes, la qualité des API et la standardisation qu'on peut trouver dans le monde java font des miracles.
Alors c'est vrai que java demande peut-être plus de ressources physiques pour bien tourner. Mais le prix du matériel n'est pas souvent un frein pour le choix d'une technologie.
Et une appli JSF bien écrite tournera de manière satisfaisante sur du matériel adapté.

Pour répondre à tes questions :
Développer en JSF c'est à la fois difficile et facile.
Difficile parce que pour que ça soit performant il faut utiliser pas mal de frameworks qui sont assez abstraits et qui masquent les comportements rééls. Et ce n'est pas toujours facile à appréhender.
Et facile parce que quand on a compris la façon de voir les choses dans le monde J2EE, on avance très vite. Et aussi parce que la richesse, la qualité et la puissance des outils est impressionnante.

Les règles d'or à suivre ? Je dirais les mêmes qu'en PHP. Faire les choses intelligemment. C'est assez difficile d'être exhaustif, mais en gros le principe c'est "éviter de faire des choses qui prennent du temps".
Le point sur lequel on peut gagner le plus en perf c'est les accès à la base de données. Que ce soit de faire des requêtes inutiles ou bien des requêtes mal construites.

[tchize_]

un autre commentaire sur les perfs de jsf. On avait besoin au boulot de faire une appli de gestion du personnel. Les données à gérer étaient kilométriques, on en est à plus de 300 champs dans le formulaire. On a travaillé en JSF, le "client" a demandé régulièrement et continue de demander des champs supplémentaire, certains assez complexes. On a travaillé avec JSF + Facelets + Hibernate au début. Ensuite, pour combler une première lenteur, on a utilisé Richfaces et ajax4jsf pour avoir des panneaux à onglet dont seulement une partie est raité à la fois. La convertion à été rapide (tout géré par le composant) et le resultat intéressant (gain signifiant de perfs). On a aussi attaqué la deuxième raison (un peu bete) de la lenteur. L'ensemble des dropsdown. Comme on gérait un formulaire ou on voulait tout accessible (pas de système à la wizard ou sectionné) pour la facilité de l'utilisateur, le fichier html générer faisait plusieur M). encore une fois on a aisément converti toutes les dropdown en popup, ce qui évitait de les chargé, en créant un simple composant custom.

Par rapport à struts 1 (struts 2 pas encore pret quand on a commencé projet d'ou choix de jsf), on a gagné sur plusieurs points

1) vitesse de développement grace au découplage entre les beans , les actions et le formulaire (avec struts faut coder un form qui fait le transfert vers les bean, c'est lourd et long)
2) pour les mêmes raisons, souplesse de mises à jour. En quelques heures, on peux ajouter des champs dans la db et les rendre visible dans l'interface
3) souplesse du design, on a séparé le formulaire du design web via les templates facelets
4) performances d'exécution, facelets étant beaucoup plus rapide à parser que du jsp d'après moi. Or struts se base sur du jsp.

par contre, comme tout outil, faut un peu de maitrise pour savoir bien l'utiliser et éviter les pièges. Il faut bien comprendre comment fonctionne le lifecycle jsf, beaucoup de "phénomène bizzares" expérimentés en tant que débutant viennent d'une méconnaissance du cycle de vie JSF. Me souviens sur un autre projet, d'avoir jouer une semaine avec un phaselistener pour obtenir qqch; deux mois plus tard, me suis rendu compte que j'aurais pu faire la meme chose avec juste une managed property (soit en 1 heure montre en main)

[scanlan]

Je reposte au lieu de modifier mon commentaire précédent, saisi un peu vite hier soir :
Pour tempérer ce que je disais concernant la facilité d'utilisation, il faut peut être que j'explique les besoins que j'ai eu/j'ai à implémenter : des tables importantes (max de 300 lignes), champs éditables si besoin, sachant que la modification de certains champs nécessite la mise à jour d'une colonne entière, sélection multiple ou simple, tri multiple, context menu pour permettre certaines actions sur les lignes sélectionnées, conversion PDF et XLS si besoin. Tout ça sur la même table.
Bref, du grand n'importe quoi, d'où l'immense bordel mis en place et des rapports parfois orageux avec JSF (même si RichFaces permet énormément de choses)

Donc JSF c'est bien quand on utilise un framework sympathique comme RichFaces ou Tomahawk en plus. Par contre je reste sceptique sur les performances (hors cas des tables qui font le café).

[tchize_]

Je trouve, personellement, la combo jsf + facelets beaucoup plus légère et rapide que les tags jsp clasique ou la combo jsp + jsf (à fuir comme la peste, sachant que jsp a un cycle de vie simple et jsf un cycle de vie en plusieurs étapes, ce qui les rend proprement peut compatible et entrainet des curioisités quand on y fait pas gaffe).

JSF est en lui même très performant. Le goulot d'étranglement c'est surtout les backing beans, certaines librairies (exemple, le filtre tomahawk, en config par défaut, qui garde toute la réponse en mémoire, la parse et y injecte le javascript) et d'autres erreurs de config (exemple, stocker la session jsf coté client en utilisant la sérialization par défaut + de gros beans).

J'ai personellement trouvé jsf, par rapport à struts, rafraichissant coté performance (une fois configuré correctement).

Pour m'être baladé dans le code source de myfaces, il n'y a rien de super compliqué là dedans. Il n'y a pas énormément d'allocations et les boucles sont relativement directes. hormis les composants se trouvant dans des itérateurs, les de composants ne sont appelés qu'une fois par phase, donc pas de longue bocle possible. Par contre, pour revenir à ton exemple (la table qui fait le café), il ne faut pas utiliser les composant préfabriqué en dehors de leur domaine d'utilisation prévue. Par exemple, mettre une radio par ligne dans un datatable, c'est pas prévu (chaque ligne est indépendante, on ne peut donc pas regrouper les radios par défaut). Il suffit soit de prendre une librairie le faisant déjà (doit être dispo dans tomahawk pour ce cas) ou de créer son propre composant (c'est le premier le plus dur, après çà va sur des roulettes pour les faires)