Primefaces Vs Icefaces 2 Vs Richfaces

Nous bientôt commencer le développement d'une nouvelle application web et sont actuellement à l'évaluation/de proposer la technologie de la pile à utiliser.

Pour la couche de la vue, nous avons à choisir entre Primefaces, Icefaces 2 (puisque nous voulons vraiment JSF2) et Richfaces. Nos exigences de base sont regard et la sensation, la simplicité et la facilité de développement, de performance et d'évolutivité (le plus important).

Qui technologie d'affichage/cadre serait plus possible de l'effet de levier. Nous vous serions reconnaissants de toutes les entrées/les avis des experts. Aussi, si il y a d'autres recommandé de cadres, s'il vous plaît laissez-nous savoir.

Merci et Salutations

Merci de regarder ce primefaces.org/showcase/ui/dialog.jsf
Les trois partie de la différence entre PrimeFaces vs RichFaces vs IceFaces dans JSF: Partie 1, Partie 2 et Partie 3,

OriginalL'auteur gkari | 2011-05-18

  1. 9

    J'ai utilisé à la fois ICEfaces et PrimeFaces et préfèrent PrimeFaces pour deux raisons principales: l'efficacité du développement de l'INTERFACE et de la performance/temps de réponse.

    La boîte de dialogue composant illustre à la fois:

    Comparer cette PrimeFaces:

    <p:dialog widgetVar="dialog"> [content] </p:dialog>
...
<a href="#" onClick="dialog.show()">Open dialog</a>

    Dans ICEfaces:

    <ice:panelPopup rendered="#{bean.dialogOpen}"> **dialog chrome** [content]
</ice:panelPopup>

<ice:commandLink action="#{bean.showDialog}">Open dialog</ice:commandLink>

    Dans ICEfaces, vous avez besoin d'un serveur-côté aller-retour et un bean géré la propriété + action listener pour ouvrir une boîte de dialogue. Dans PrimeFaces, grâce à "widgetVar", vous pouvez lier le composant côté client variable accessible en jQuery et régulièrement des événements DHTML.

    En outre, les composants PrimeFaces poignée de nombreux de la commune cas avec moins de code; par exemple, une boîte de dialogue composant comprend la barre de titre et le "X" pour fermer, tandis que dans ICEfaces vous devez faire tourner votre propre (ou d'acheter de l'EE avec des composants composites).

    Enfin, l'automatique "AJAX" côté serveur DOM diff dans ICEfaces peut créer des problèmes de performances côté serveur si votre pages du big - la plupart du temps, vous savez ce que vous voulez vous rafraîchir, et de spécifier explicitement la mise à jour="id" sur un composant est plus efficace.

    OriginalL'auteur wrschneider

  2. 4

    Toutes les essayer dans un petit POC, quelques pages, peut-être, et ensuite décider pour vous-même. Également envisager de maturité, de soutien disponibles, les ressources disponibles, les fonctionnalités d'entreprise, etc. Dans mon expérience, A, B, C produisent rarement bon argument de savoir si pour aller avec une bibliothèque de composants ou d'une autre.

    Merci pour la suggestion Max. Je suppose que nous allons aller le POC route.

    OriginalL'auteur Max Katz

  3. 3

    J'ai essayé IceFaces et PrimeFaces et a finalement choisi PrimeFaces due à zéro de la configuration de démarrage, de la simplicité à l'utilisation de composants et de la bonne bonne intégration de JQuery.
    Je ne ratez un bon soutien pour les server-push dans PrimeFaces, tout cela est bien pris en charge dans IceFaces.

    J'ai aussi aimé celui-pot de dépendance dans PrimeFaces tout IceFaces besoins, au moins, trois jar bibliothèques de travail.

    Cordialement et bonne chance.

    Je vous remercie beaucoup. De ce que j'ai lu sur internet jusqu'à présent, je me penche vers Primefaces moi-même. J'ai travaillé avec Icefaces largement et nous avons utilisé l'ajax push lourdement, mais il a également conduit à un grand nombre d'indésirables de rendu cycles.

    OriginalL'auteur frandevel