>Objet XmlHttpRequest...
>Marche très très bien, est rapide, te permet rapidement de parser le
>flux XML renvoyé par le serveur (par exemple)...
Je ne doute pas, mais tu seras quand même obligé de collecté toutes les données de ton interface à la main pour construire ton message XML que tu transmettra au serveur.
De même, tu effectuera un traitement similaire pour la réception du retour. Je me trompe ?
Dans un autre langage, tu effectuera la même opération côté serveur.
Dans un formulaire HTML, tu n'as pas besoin d'effectuer la première opération. Elle correspond à la reconstruction de l'interface avec le rechargement de la page.
Si le langage associé à la description de ton interface dans un langage tel que XUL et le même que celui executé du côté serveur.
Tu pourrais envisager d'écrire une seul fois l'objet partager entre le serveur et le client rich. Les echanges de données entre les deux parties se ferait simplement par une serialisation et deserialisation de ton objet. Pour ensuite avoir, une mise à jour automatique des champs de ton interface si celle-ci écoute le modèle.
Bref, c'est là qu'il manque quelques choses dans XUL. L'avantage de Microsoft avec XAML, c'est qu'ils ne se poseront même pas la question vu que tout est déjà integré dans .Net.
Ils ont juste à écrire le browser, la plateform fera déjà le reste !
>C'est du javascript mais c'est vraiment simple... (merci au Venkman >Debugger, le meilleur assistant au javascript sous mozilla !)
Je l'utilise en dernier recours car il plante tout le temps chez moi dès que j'ai trop d'onglet d'ouvert.
[^] # Re: XUL...
Posté par syj . En réponse au journal Les rich clients XAML , XUL, Flash/ActionScript : une bataille gagné d'avance pour Microsoft.. Évalué à 0.
>Marche très très bien, est rapide, te permet rapidement de parser le
>flux XML renvoyé par le serveur (par exemple)...
Je ne doute pas, mais tu seras quand même obligé de collecté toutes les données de ton interface à la main pour construire ton message XML que tu transmettra au serveur.
De même, tu effectuera un traitement similaire pour la réception du retour. Je me trompe ?
Dans un autre langage, tu effectuera la même opération côté serveur.
Dans un formulaire HTML, tu n'as pas besoin d'effectuer la première opération. Elle correspond à la reconstruction de l'interface avec le rechargement de la page.
Si le langage associé à la description de ton interface dans un langage tel que XUL et le même que celui executé du côté serveur.
Tu pourrais envisager d'écrire une seul fois l'objet partager entre le serveur et le client rich. Les echanges de données entre les deux parties se ferait simplement par une serialisation et deserialisation de ton objet. Pour ensuite avoir, une mise à jour automatique des champs de ton interface si celle-ci écoute le modèle.
Bref, c'est là qu'il manque quelques choses dans XUL. L'avantage de Microsoft avec XAML, c'est qu'ils ne se poseront même pas la question vu que tout est déjà integré dans .Net.
Ils ont juste à écrire le browser, la plateform fera déjà le reste !
>C'est du javascript mais c'est vraiment simple... (merci au Venkman >Debugger, le meilleur assistant au javascript sous mozilla !)
Je l'utilise en dernier recours car il plante tout le temps chez moi dès que j'ai trop d'onglet d'ouvert.