Pourquoi JSF doit-il enregistrer l’état des composants de l’interface utilisateur côté serveur?

Parce que HTTP est sans état et JSF avec état. L’arborescence des composants JSF est soumise à des modifications dynamics (programmatiques). JSF doit simplement connaître l’état exact tel qu’il était lorsque le formulaire avait été affiché à l’utilisateur final, afin qu’il puisse traiter avec succès l’ensemble du cycle de vie JSF sur la base des informations fournies par l’arbre de composants JSF original lorsque le formulaire a été renvoyé à le serveur. L’arborescence des composants fournit des informations sur les noms des parameters de la demande, les convertisseurs / validateurs nécessaires, les propriétés des beans gérés liés et les méthodes d’action.

Jusqu’à quel moment JSF enregistre-t-il l’état des composants de l’interface utilisateur côté serveur et à quel moment les informations d’état du composant d’interface utilisateur sont-elles supprimées de la mémoire du serveur?

Ces deux questions semblent se résumer à la même chose. Quoi qu’il en soit, cela est spécifique à l’implémentation et dépend également de la sauvegarde de l’état sur le serveur ou le client. Une implémentation un peu décente la supprimera lorsqu’elle aura expiré ou lorsque la queue sera saturée. Mojarra, par exemple, dispose d’une limite par défaut de 15 vues logiques lorsque la sauvegarde de l’état est définie sur session. Ceci est configurable avec le paramètre contextuel suivant dans web.xml :

  com.sun.faces.numberOfLogicalViews 15  

Voir aussi la FAQ Mojarra pour d’autres parameters spécifiques à Mojarra et la réponse associée com.sun.faces.numberOfViewsInSession vs com.sun.faces.numberOfLogicalViews

Lorsqu’un utilisateur connecté sur l’application navigue sur des pages, l’état des composants continuera-t-il de s’accumuler sur le serveur?

Techniquement, cela dépend de l’implémentation. Si vous parlez de navigation de page en page (uniquement des requêtes GET), Mojarra ne sauvegardera rien en session. S’il s’agit toutefois de requêtes POST (formulaires avec liens de commande / boutons), Mojarra enregistrera l’état de chaque formulaire en session jusqu’à la limite maximale. Cela permet à l’utilisateur d’ouvrir plusieurs formulaires dans différents tabs de navigateur au cours d’une même session.

Ou, lorsque la sauvegarde d’état est définie sur client, JSF ne stocke rien dans la session. Vous pouvez le faire par le paramètre de contexte suivant dans web.xml :

  javax.faces.STATE_SAVING_METHOD client  

Il sera ensuite sérialisé en une chaîne cryptée dans un champ d’entrée masqué nommé javax.faces.ViewState du formulaire.

Je ne comprends pas quel est l’avantage de conserver l’état du composant d’interface utilisateur côté serveur. La transmission directe des données validées / converties aux beans gérés n’est-elle pas suffisante? Puis-je / dois-je essayer de l’éviter?

Ce n’est pas suffisant pour assurer l’intégrité et la robustesse de JSF. JSF est un cadre dynamic avec un seul sharepoint contrôle. Sans une gestion d’état, il serait possible d’usurper / pirater des requêtes HTTP d’une certaine manière (par exemple en manipulant disabled atsortingbuts disabled , en readonly ou rendered ), pour permettre à JSF de faire des choses différentes et potentiellement dangereuses. Il serait même sujet aux attaques CSRF et au phishing.

Et cela ne consum-t-il pas trop de mémoire côté serveur, s’il existe des milliers de sessions utilisateur simultanées? J’ai une application où les utilisateurs peuvent publier des blogs sur certains sujets. Ces blogs sont assez volumineux. Lorsqu’il y aura une publication ou une demande de consultation des blogs, les gros blogs seront enregistrés dans le cadre de l’état des composants. Cela consumrait trop de mémoire. N’est-ce pas une préoccupation?

La mémoire est particulièrement bon marché. Il suffit de donner au serveur d’applications suffisamment de mémoire. Ou, si la bande passante du réseau est moins chère, il vous suffit de basculer la sauvegarde de l’état vers le côté client. Pour trouver la meilleure correspondance, il vous suffit de tester et de profiler votre application Web avec le nombre maximum d’utilisateurs simultanés attendus, puis de donner au serveur d’applications 125% ~ 150% de la mémoire mesurée maximale.

Notez que JSF 2.0 s’est beaucoup amélioré dans la gestion des états. Il est possible de sauvegarder un état partiel (par exemple, seul le sera enregistré à la place de l’intégralité de jusqu’à la fin). Mojarra par exemple fait cela. Un formulaire moyen avec 10 champs de saisie (chacun avec une étiquette et un message) et 2 boutons ne prendrait pas plus de 1 Ko. Avec 15 vues en session, cela ne devrait pas dépasser 15 Ko par session. Avec ~ 1000 sessions utilisateurs simultanées, cela ne devrait pas dépasser 15 Mo.

Votre préoccupation devrait être davantage axée sur les objects réels (beans gérés et / ou même entités de firebase database) dans le cadre d’une session ou d’une application. J’ai vu beaucoup de codes et de projets qui dupliquent inutilement la totalité de la table de firebase database dans la mémoire de Java en fonction d’un bean de session où Java est utilisé au lieu de SQL pour filtrer / grouper / organiser les enregistrements. Avec environ 1000 enregistrements, cela dépasserait facilement 10 Mo par session utilisateur .