Discussion :

[soad]

Hello tout le monde...

Alors voilà, je suis nouveau et j'aimerais savoir quand est-ce qu'il faut utiliser des DetachableModel ou inversément des modèle non détachable ?

J'ai bien compris que les DetachableModel ne sont pas stocké en session mais quand est ce que c'est néssaire de stocker un modèle en session ?

Et pour finir, combien de temps reste un modèle en session ?

Merci d'avance

[Nithril]

Hello tout le monde...

Alors voilà, je suis nouveau et j'aimerais savoir quand est-ce qu'il faut utiliser des DetachableModel ou inversément des modèle non détachable ?

J'ai bien compris que les DetachableModel ne sont pas stocké en session mais quand est ce que c'est néssaire de stocker un modèle en session ?

Et pour finir, combien de temps reste un modèle en session ?

Merci d'avance

Il peut etre necessaire de stocker un modèle en session quand les valeurs exposées par le modèle ne sont pas persisté. Ex : un formulaire de recherche.

Le DetachableModel est généralement utilisé pour exposé des données persistées en base.

Le modele reste au minimum en session tant qu'il est référencé par un composant wicket et au maximum la durée de ta session.

En esperant t'avoir aidé (ou de n'avoir pas dit de betise... )

[joseph_p]

la réponse de Nithril me semble bonne.

Je rajouterai juste que, pour éviter que les sessions ne prennent trop de place ("session bloat"), il est important d'éviter d'y mettre trop de choses.

Justement, le LoadableDetachableModel permet d'éviter de mettre des choses inutiles : en effet, il est à utiliser dès qu'un élément te permet de charger tout un objet. Concrètement, si tu as une table derrière ton objet, sa clé te permettra de le retrouver si nécessaire : tu peux (et dois) ne stocker qu'elle dans la session.

Cela est valable et à faire pour toute donnée accessible via un identifiant (ou plus généralement via ta surchage de la méthode load).

Pour la durée de vie des objets sérialisés, je dirai qu'elle dépend du nombre de pages que tu gardes dans ta pageMap pour supporter le retour arrière. (je ne me souviens plus de la valeur par défaut j'avoue )

[soad]

Merci pour vos réponses...

mais je prend un exemple :

J'ai une page web multilingue. Le texte affiché est donc contenu dans un Label wicket pour afficher le texte dynamiquement en fonction de la langue.

Si je créer mon Label ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
 
ResourceBundle resource = ResourceBundle.getBundle("language");
 
Form f = new Form("formInscription");
f.add(new Label("txt1", resource.getString("txt1")));
 
add(f);

Est-ce que le modèle du Label sera en session ?

Merci

[Nithril]

Oui il sera stocké en session

[soad]

Oui il sera stocké en session

Donc chose qui est inutile !?!

Est-ce qu'il vaudrait mieux faire comme cela ??? :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
ResourceBundle resource = ResourceBundle.getBundle("language");
 
Form f = new Form("formInscription");
f.add(new Label("txt1", new LoadableDetachableModel(resource.getString("txt1"))));
 
add(f);

Et encore une autre petite question :

Si je reprend mon code de départ :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
ResourceBundle resource = ResourceBundle.getBundle("language");
 
Form f = new Form("formInscription");
f.add(new Label("txt1", resource.getString("txt1")));
 
add(f);

Quand l'utilisateur changera de page, les données seront-elles supprimées de la session ?

[Nithril]

Rien ne t'empeche de surcharger le getObject de ton model pour envoyé directement la valeur de ton resource.getString("txt1")

Par contre "txt1" sera forcement stocké en session.

Ou mieux, tu peux utiliser les ResourceModel/StringResourceModel.

Comme l'a dit ZedroS, Wicket gère une pagemap pour gérer le back du navigateur. Lors d'un changement de page suivant la taille de la pagemap, la page quitté sera toujours stockée en session.

[joseph_p]

Est-ce qu'il vaudrait mieux faire comme cela ??? :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
ResourceBundle resource = ResourceBundle.getBundle("language");

re

rapido : de mémoire de lecture de mailing list, wicket ne garde pas les ressources en session mais au niveau de l'application, ce qui fait bien plus sens (pour éviter que chaque page ait à aller voir effectivement le fichier correspondant).

Le LoadableDetachableModel s'applique surtout aux données issues d'une base de données, pour lesquelles tu peux aisément retourner les chercher. Combien même d'ailleurs, si tu utilises un minimum de cache, alors là encore ces données ne seront que rarement réellement cherchées en base, mais c'est une autre histoire

++

[soad]

re

rapido : de mémoire de lecture de mailing list, wicket ne garde pas les ressources en session mais au niveau de l'application, ce qui fait bien plus sens (pour éviter que chaque page ait à aller voir effectivement le fichier correspondant).

C'est à dire ? C'est bien correct d'utiliser des ResourceBundle pour faire des sites multilingues, non ?

[joseph_p]

wicket propose toute une floppée d'outils pour l'internationalisation, basé sur des fichiers properties. Plus d'info là :
http://cwiki.apache.org/WICKET/i18n.html
on parle bien de ça ?

Si oui, on peut y lire dans http://cwiki.apache.org/WICKET/every...alization.html :

Reloading and caching

When Wicket is started in development mode, changed properties files are detected and reloaded. To properly make use of this feature from an IDE, you should run Wicket directly from the compiled sources, for example with the Start file, included in every QuickStart. In Eclipse you just save the properties file, in IntelliJ you must do a make (Ctrl-F9) before changes are picked up.
In production mode, resolved properties are heavily cached for performance. (Same applies to html files.)

[soad]

Oui on parle bien de l'internationalisation...
ha ouais ok.. je connaissais pas la balise <wicket:message key>, ca risque de simplifier les choses...

Merci beaucoup

[joseph_p]

si tu ne connaissas pas l'intertionalisation dans wicket, je te conseille vivement de regarder de plus près.

Il y a notamment un parcours différent des fichiers propriétés, avec une notion de hiérarchie.

Autrement dit, wicket cherche en 1er lieu par rapport au composant en cours, puis remonte dans les différents composants de la hiérarchie. Cela offre en fait la possibilité de surcharger d'éventuelles valeurs par défaut.

Concrètement, tu peux définir à un seul endroit des propriétés globales, au niveau de l'application, et ne les surcharger qu'à côté des composants où cette valeur par défaut ne s'applique pas. De même, chaque composant offert avec wicket a son fichier de propriété à côté, que tu peux surcharger via un fichier propre à la classe où le composant est utilisé (en déclarant à nouveau la clé que tu veux utiliser/modifier dans ton fichier propriété).

On a donc là encore des traductions par défaut aisément modiables. Sympa non ?

NB : le sujet est il résolu ?

[soad]

Oui le sujet est résolu ! Merci beaucoup pour votre aide !