Bonjour,
Je fais des essais avec les websockets et tous les exemples m'invitent à entrer ce type de script côté client :
ou quand même plus simplement ceci (lu dans ce lien) :
Code : Sélectionner tout - Visualiser dans une fenêtre à part 
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Et je n'aime pas beaucoup le Javascript.
Code : Sélectionner tout - Visualiser dans une fenêtre à part 
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Quand j'en vois placé dans du JSF 2.x, je me dis qu'on le dévoie.
JSF 2.2 n'était-il pas supposé supporter les websockets ? Il me suis persuadé que j'aurais du trouver autre chose que cela pour lui faire émettre et recevoir des données.
En particulier, je vais avoir n méthode sendXXX() : une par élément (ou par série d'éléments) dans la page qui ont un motif d'expédier quelque-chose à un instant donné, en adressant des sockets différentes. Mais une seule méthode onMessage() qui elle va grossir, grossir, imaginez par exemple qu'on peut me répondre pour :
- valider un l'e-mail d'un simple message directement formaté en HTML comme dans cet exemple,
- ou avec l'image de la voiture que je veux regarder,
- ou avec une structure de données qui me valide trois éléments de ma page à la fois en me passant des triplets (code de champs, sévérité, texte d'anomalie).
Ça va être la pagaille, non ?
Parser evt.data va se révéler sauvage j'en ai peur : comment pour détecter qui a répondu à qui ? Grâce à un protocole en mousse que je ferai maison ?
C'est moi qui fait ma diva et qui me choque pour rien ?
Merci !
Grunt.

 

 
		
		 
        

 
			
			


 
 
 
   


 JSF et websockets : un long <script> javascript est obligatoire ?
 JSF et websockets : un long <script> javascript est obligatoire ?
				 Répondre avec citation
  Répondre avec citation
Partager