> 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.
Oui, et en utilisant une partie de ton cerveau, tu pourra même te réaliser une petite bibliothèque qui te permettra de faire tout ça en 2 lignes de code. (ou au pire, en récuperer une déjà toute faîte..)
> De même, tu effectuera un traitement similaire pour la réception du retour. Je me trompe ?
non, et alors ?? ça s'appelle faire appel à des services web (tu sais le truc qui te permet justement de tout garder tes objets metiers coté serveur, et de pouvoir les utilisé depuis n'importe où : appli web, client desktop etc...)
> Dans un autre langage, tu effectuera la même opération côté serveur.
euh, excuse moi, mais le serveur il est toujours là pour faire des traitements metier.
Je dirais même que ton appli en xul sera plus performante et le serveur moins surchargé, car il n'a plus à regénérer l'interface graphique d'un formulaire à chaque fois que l'on veut changer un truc dans le formulaire.
Il fait juste les traitements qu'on lui demande de faire au travers de services web.
(Mozilla sait faire du SOAP nativement, donc à priori, il n'y as pas 15000 lignes de code JS à écrire pour faire appel à un web service afin de poster le contenu d'un formulaire et récuperer l'éventuel résultat,dans le cas d'un formulaire de recherche par exemple)
>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.
et tu trouve ça efficace ?
moi non. et pas super friendly pour l'utilisateur.
essaye http://mab.mozdev.org.(...)
exercice : faire la même chose classiquement en HTML/PHP, tout en étant aussi friendly, ergonomique etc... (on comparera le nombre de ligne de code en JS ok ? ;-)
> 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.
t'es un tueur toi non ? Ta dévise ne serait-elle pas "pourquoi faire simple quand on peut faire compliqué" ?
> 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 !
[^] # Re: XUL...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les rich clients XAML , XUL, Flash/ActionScript : une bataille gagné d'avance pour Microsoft.. Évalué à 4.
Oui, et en utilisant une partie de ton cerveau, tu pourra même te réaliser une petite bibliothèque qui te permettra de faire tout ça en 2 lignes de code. (ou au pire, en récuperer une déjà toute faîte..)
> De même, tu effectuera un traitement similaire pour la réception du retour. Je me trompe ?
non, et alors ?? ça s'appelle faire appel à des services web (tu sais le truc qui te permet justement de tout garder tes objets metiers coté serveur, et de pouvoir les utilisé depuis n'importe où : appli web, client desktop etc...)
> Dans un autre langage, tu effectuera la même opération côté serveur.
euh, excuse moi, mais le serveur il est toujours là pour faire des traitements metier.
Je dirais même que ton appli en xul sera plus performante et le serveur moins surchargé, car il n'a plus à regénérer l'interface graphique d'un formulaire à chaque fois que l'on veut changer un truc dans le formulaire.
Il fait juste les traitements qu'on lui demande de faire au travers de services web.
(Mozilla sait faire du SOAP nativement, donc à priori, il n'y as pas 15000 lignes de code JS à écrire pour faire appel à un web service afin de poster le contenu d'un formulaire et récuperer l'éventuel résultat,dans le cas d'un formulaire de recherche par exemple)
>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.
et tu trouve ça efficace ?
moi non. et pas super friendly pour l'utilisateur.
essaye http://mab.mozdev.org.(...)
exercice : faire la même chose classiquement en HTML/PHP, tout en étant aussi friendly, ergonomique etc... (on comparera le nombre de ligne de code en JS ok ? ;-)
> 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.
t'es un tueur toi non ? Ta dévise ne serait-elle pas "pourquoi faire simple quand on peut faire compliqué" ?
> 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 !
bien sûr...et la marmotte...