Pourquoi JSF enregistrer l'état d'arborescence des composants?

Question

Il semble y avoir une différence entre l'état de haricot géré et l'état d'arborescence des composants. Vous pouvez contrôler l'état géré bean en utilisant des annotations comme @RequestScoped et @SessionScoped , mais il semble que vous n'avez pas le choix si l'état d'arborescence des composants est enregistré ou non (bien que vous pouvez choisir s'il est enregistré sur le serveur ou client).

Il semble que l'état d'arborescence des composants ne doit être nécessaire pour la durée d'une seule demande en tant que structure de données temporaire processus d'aide une demande. Il doit être reconstruit à partir de zéro pour chaque demande. Avec l'économie d'état partiel JSF 2.0 rend la situation meilleure, car les données ne forme est enregistrée, mais je ne comprends pas pourquoi avoir même des données font de la requête précédente est utile.

Si votre application utilise demande uniquement les beans gérés scope alors il ne surtout pas de sens pour sauver l'état d'arborescence des composants entre les requêtes. Même si votre application a une portée de session géré les haricots, je suppose que les haricots gérés détiendraient l'état et l'arborescence des composants ne serait toujours pas besoin d'avoir un état entre les demandes.

Answer 1

Parce que l'arborescence des composants peut être modifié en fonction de la programmation demande initiale. Ce n'est pas nécessairement à la demande reproductible après chaque fois que les données de formulaire doit être traité.

En outre, j'ai l'impression que vous pensez que l'arborescence des composants détient également les valeurs du modèle. Ce n'est pas vrai. Il ne contient que des références (selon la langue d'expression) aux valeurs du modèle (les propriétés de haricots gérés). L'état d'affichage ne copie / double / contient pas l'état du modèle. Il est juste un arbre pur composant d'interface utilisateur. Peut-être votre confusion est basée sur ce point. Notez que le terme « données de formulaire » doit être interprété comme des valeurs et des valeurs du modèle soumis.

Voir aussi:

• Pourquoi JSF enregistre l'état des composants d'interface utilisateur sur le serveur?

Answer 2

Ajout à la réponse précédente, depuis JSF 2.0 quelque chose appelé partial state saving est utilisé par défaut.

La langue d'affichage par défaut de description dans JSF (Facelets) crée l'arbre entier composant du Facelet d'origine après chaque demande et initialise les composants de leurs attributs de la balise correspondant. Il a ensuite marques l'État.

Chaque modification ultérieure de l'état est alors dans les mémoires comme un changement delta, et il est cet état qui est en fait en cours d'enregistrement. Il pourrait juste bien se qu'il n'y a tout simplement pas de tels changements, et l'état d'affichage est vide (à cause d'un bug, l'état n'a jamais été vraiment vide, mais qui a été récemment fixé Voir http://java.net/jira/browse/JAVASERVERFACES-2203 pour plus de détails)

Alors la grande question est, ce qui est en fait dans cet état alors quand il est? Non vide

Comme BalusC déjà fait remarquer, cela pourrait tenir des changements dynamiques à l'arborescence des composants. Ces changements peuvent être soit lancées à partir de fèves de support, ou à partir de composants statiques. Un exemple simple du type de composant qui fait ce changement de dynamique est un élément de table qui crée des composants de la colonne de l'enfant en fonction du nombre réel de colonnes dans un ensemble de données.

Une autre utilisation importante pour l'état d'affichage est de se rappeler les valeurs qui ont été modifiées à l'intérieur des composants, mais ne l'ont pas été poussé dans le modèle. Cela peut être des choses telles que un interrupteur dans effleurant un composant de commutation, le déplacement d'un curseur dans un composant de numérotation, etc.

Un exemple particulier est le composant viewParam, qui mémorise le paramètre de demande (paramètre de chaîne de requête GET ou non faces paramètre POST) avec lequel il a été initialisé. Voir cela pour un peu plus d'informations à ce sujet: http : //arjan-tijms.omnifaces.org/2011/07/stateless-vs-stateful-jsf-view.html

Il y a aussi une relation forte avec des composants stateful état de l'interface utilisateur se souvenir et de la conversion ou de validation qui échoue. Dans ce cas, les composants de l'interface utilisateur se souviendront des valeurs saisies par l'utilisateur et se souviendront qu'il y avait une erreur de conversion / validation.

Une autre utilisation de l'état est l'optimisation. Certains composants calculent des valeurs qu'ils jugent être coûteux pour calculer et stocker dans l'état d'affichage. Par exemple, les composants UIInput font après le premier post-retour:

private boolean validateEmptyFields(FacesContext ctx) {

    if (validateEmptyFields == null) {
        ExternalContext extCtx = ctx.getExternalContext();
        String val = extCtx.getInitParameter(VALIDATE_EMPTY_FIELDS_PARAM_NAME);

        if (val == null) {
            val = (String) extCtx.getApplicationMap().get(VALIDATE_EMPTY_FIELDS_PARAM_NAME);
        }
        if (val == null || "auto".equals(val)) {
            validateEmptyFields = isBeansValidationAvailable(ctx);
        } else {
            validateEmptyFields = Boolean.valueOf(val);
        }
    }

    return validateEmptyFields;

}

Après cette validateEmptyFields est stocké dans l'état d'affichage de sorte qu'il ne doit pas être calculé à nouveau sur les soumet de formulaire ci-dessous. Une amélioration serait si les utilisateurs peuvent choisir entre recalcul ou le stockage (le connaissent bien l'optimisation de l'espace de temps).

Le concept même de l'Etat est ce qui a le développement d'applications web pestiférée depuis sa conception au début. Tout le monde veut avoir des interactions qui sont essentiellement stateful, mais presque personne ne veut manipuler ou même de penser à ce sujet.

JSF a essayé de fournir une réponse, mais il est évidemment pas parfait et il y a place à l'amélioration. L'insistance de JSF d'être en mesure de rétablir l'état d'affichage (même état d'affichage vide) peut être gênant, même si, comme cela a été mentionné dans une autre réponse, il ne fournit une protection implicite contre CSRF. JSF 2.2 obtiendra la protection CSRF plus explicite (voir par exemple http: // Arjan -tijms.omnifaces.org/p/jsf-22.html#869 ), nous allons peut-être voir un changement ici à l'avenir.

Avoir une option pour désactiver l'état par composant et ayant un crochet facile à restaurer l'état Incase le cadre ne peut pas (comme dans ASP.NET) pourrait également être utile.