JSF ui:fragment rendu de la performance

J'ai un ensemble de composants jsf de manière statique générée à partir d'un ensemble de fichiers excel (ils sont mis à jour par des gens d'affaires). Chaque fichier généré représente un objet métier qui est légèrement différente des données, et elles appartiennent toutes à une même classe.

Afin de rendre ce, de façon dynamique, la seule solution que j'ai trouvé était de mettre en place un groupe de ui:fragment et l'expédition vers la droite composant à l'exécution:

<!-- IMPLEMENTATION -->          
<composite:implementation> 
    <ui:fragment rendered="#{cc.attrs.type eq 'cartcred'}">
        <limites:limites-cartcred  limite="#{cc.attrs.limite}"/>
    </ui:fragment>
    <ui:fragment rendered="#{cc.attrs.type eq 'cdcp'}">
        <limites:limites-cdcp limite="#{cc.attrs.limite}"/>
    </ui:fragment>
    <ui:fragment rendered="#{cc.attrs.type eq 'cheqpredatado'}">
        <limites:limites-cheqpredatado limite="#{cc.attrs.limite}"/>
    </ui:fragment>
    <ui:fragment rendered="#{cc.attrs.type eq 'confirming'}">
        <limites:limites-confirming limite="#{cc.attrs.limite}"/>
    </ui:fragment>
   <!-- many more lines -->
   <!-- many more lines -->
   <!-- many more lines -->
    <ui:fragment rendered="#{cc.attrs.type eq 'contacorr'}">
        <limites:limites-contacorr limite="#{cc.attrs.limite}"/>
    </ui:fragment>

Mais j'ai trouvé que la performance de ce est terrible. Je tought que JSF ne ferait que rendre un seul composant, mais il semble que c'est rendu tous d'entre eux et de "cacher" les autres au moment de l'exécution.

Est-il un moyen plus efficace d'atteindre mon objectif? Je veux rendre un seul composant basée sur les informations d'exécution sur une entreprise de classe (un peu comme un if-then-else), mais je ne peut déterminer ce qui est le composant de rendre à l'exécution.

Précisions:
ce qui se passe, c'est que chaque composant référencé par limites:limites* est un énorme complexe de page avec beaucoup d'autres composants. Au moment de l'exécution, le paramètre nommé type' will decide what component to render. But my tests show that if I only render one component, but leave the otherde l'interface utilisateur:fragments (même en sachant qu'ils ne seront pas rendus), il va rendre beaucoup plus lent que si je supprimer les composants.

Donc si ma page est exactement comme ceci:

<composite:interface>
    <composite:attribute name="type" required="true" />
    <composite:attribute name="limite" required="true" />
</composite:interface>         
<composite:implementation> 
    <ui:fragment rendered="#{cc.attrs.type eq 'cartcred'}">
        <limites:limites-cartcred  limite="#{cc.attrs.limite}"/>
    </ui:fragment>
</composite:implementation>

il va rendre beaucoup (10x) plus rapide que la version initiale, même si les paramètres sont les mêmes. Je soupçonne que JSF va créer l'ensemble de la composante de l'arbre et seulement à l'exécution, il décidera (selon le paramètre fourni) si il va rendre les uns les autres ou pas.

Modifier

Y est presque. J'ai juste besoin de ma composite composant dynamiquement. J'ai essayé de l'évaluation d'un ELExpression mais cela ne fonctionne pas. Ce dont j'ai besoin est un moyen d'accéder à l'étendue actuelle au sein de la composante de la création, et l'utilise pour générer le bon nom de fichier:

//obviously, ELExpressions don't work here
Resource resource = application.getResourceHandler().createResource("file-#{varStatus.loop}.xhtml", "components/dynamicfaces");

OriginalL'auteur Miguel Ping | 2011-05-16

2

Une possibilité pourrait être d'utiliser le binding attribut d'accéder à un conteneur
composant à partir de l'intérieur de votre managed bean et construire le composant de l'arbre de la
java côté. De cette façon, vous pourriez inclure uniquement les composants nécessaires, inutiles
les composants ne seront pas évaluées.

JSP:
```
<h:panelGroup binding="#{managedBean.panel}"/>
```
Managed Bean:
```
private UIPanel panel;

//getter and setter


//Action method, might also work in a @PostConstruct
public String showComponent() {
    if (showComponent1) {
        UIOutput component1 = new HtmlOutputText();
        component1.setValue("Hello world!");

        getPanel().getChildren().add(component1);
    }

    return "viewId";
}
```
Je n'ai pas utilisé cet ensemble avec des composants composites pourtant, cette question semble avoir un peu plus de détails et un exemple d'application concernant l'utilisation de ce avec des composants composites.

Edit: Concernant votre montage, vous pouvez également évaluer EL expressions dans votre bean géré comme ceci:
```
FacesContext facesContext = FacesContext.getCurrentInstance();
ELContext elContext = facesContext.getELContext();
ExpressionFactory exprFactory = facesContext.getApplication().getExpressionFactory();
ValueExpression expr = exprFactory.createValueExpression(elContext, "#{expr}", String.class);
String value = (String) expr.getValue(elContext);
```
Cela a fonctionné, même si elle ne résout pas mon problème, je pense que c'était une bonne réponse.
merci, merci de voir ma mise à jour pour un exemple d'utilisation de el expressions à partir du code java.
Hehe merci, j'ai déjà essayé de l'évaluation de la ELExpression sur le haricot, mais pour quelque raison il n'a pas d'évaluer correctement; il ne pourrait probablement pas résoudre les variables que j'essayais d'accès au moment de la setComponent est appelé. Parfois vous avez juste à passer.

OriginalL'auteur Jörn Horstmann
8

Oui, le rendered attribut évalue pendant le temps de rendu, pas pendant le temps de construction. Oui, il est assez terrible. Imaginez qu'un tel état de coûts de 1 ms, l'évaluation de dix d'entre eux prendrait au total 10 fois plus longtemps, 10ms. Si vous tournez en avoir dix de ces éléments dans un tableau paginé, la webapp temps de chargement prendrait 0,1 seconde de plus. Environ un clignement de paupières plus. Mais si vous n'avez pas paginer et/ou l'utilisation d'MSIE comme référence navigateur, alors il faudrait beaucoup plus de temps. Êtes-vous de la pagination des données et des essais appropriés navigateurs?

Meilleur de ce que vous pourriez faire est de remplacer le <ui:fragment> par des balises JSTL comme <c:if>/<c:choose> afin qu'il évalue au cours de la construction, non pas pendant le temps de rendu. Ou, alternativement, de construire le composant de l'arbre dans la sauvegarde de haricot constructeur au lieu de en vue.

Je ne peux pas paginer, parce que la page générée est utilisée à des fins d'impression. Depuis la page mentionnée ci-dessus est générée à partir de xls de métadonnées, ce que je veux vraiment savoir, c'est comment puis-je m'assurer que le fragment contenus ne sont "traitées" si la condition est évaluée à true. D'ailleurs, ma référence navigateur est MSIE6. Je devrais chercher un autre job...
MSIE a une très mauvaise table HTML les performances de rendu. Je doute si votre problème est en fait causée par EL. Il est extrêmement rapide. Essayez de tester la même page dans les autres navigateurs, par exemple Firefox ou Chrome juste pour votre propre référence.
J'ai précisé mon problème.
J'ai mis à jour la réponse à essayer de JSTL au lieu de construire la vue.
JSTL n'a pas fonctionné comme je l'espérais. Mon cas était un peu plus factice que l'exemple que j'ai posté, mais merci quand même.

OriginalL'auteur BalusC

Vous devez vous connecter pour publier un commentaire.