> Le problème, c'est que XUL/EcmaScript ne repondent pas aux besoins des entreprises.
permet moi d'en douter
>Tu pourras faire une interface graphique à peine plus complexe qu'avec du XHTML/CSS/EcmaScript.
ben voyons.
Un menu déroulant par exemple.
En xul : 2-3 balises à ta disposition.
En xhtml : 2-3 balises, + du code javascript dans tout les sens.
Désolé, mais il n'y a pas photo. On peut réaliser des interfaces VRAIMENT complexe avec XUL, sans que ce soit réèllement difficile.
> Mais si tu veux pouvoir réutiliser tes composants afin de les mettre à profit à d'autre endroit d'un projet. Tu ne pourra qu'en acquerant des compétences dans d'autre technologie et la tu te retrouves à te plonger dans la description: XPCOM , XBL, création de XPI.
euh... je ne vois pas ce que viennent faire XPCOM et XPI pour faire des composants graphiques réutilisables.
Dans le cas d'une appli web, tu n'as pas vraiment besoin de XPCOM ou XPI. Les traitements metiers se font toujours coté serveur web, en php java ou autre. Bref, ça ne change pas beaucoup de maintenant. Il y a juste l'interface qui change.
>Sans compter, les problèmes de déploiements de composants XPI du aux différentes versions de Mozilla.
oui mais ça, ça n'a rien à faire dans des applis web.
>A çà, tu rajoutes le développement du coté serveur dans un autre langage et tu te retrouves avec un beau mic-mac.
je ne vois pas en quoi c'est plus micmac que maintenant.
Une appli web actuellement, c'est quoi ?
HTML + CSS + JS + PHP/JAVA/autre
Une appli web en xul, c'est quoi ?
XUL (+XBL) + CSS +JS + PHP/JAVA/autre
où vois-tu que c'est plus le bordel ?
> Ou chaque développeur est irremplaçable car il n'y a que lui qui maitrise une technologies employé dans le projet.
tout développeur web maitrise un minimum HTML, CSS, JS, et PHP/JAVA/autre
Sous pretexte qu'on remplace le HTML par du XUL, il ne saurait plus rien faire ? ne saurait plus faire que du JS ou que du PHP ou... ???
>A çà, tu rajoutes toutes les parties codes qui vont être réecrite plusieurs fois. Par exemple, un objet métier et son comportement une fois en JavaScript côté client , une fois Php ou en Java côte serveur.
Ahh ? parce que pour toi, un objet metier fait parti de l'interface graphique ???? boudiou, tu as des méthodes de travail plutôt bordelique ! je comprend maintenant que tu t'en sort pas avec HTML +CSS +js + php/java/autre tout ensemble !
>ref, tu changes un attribut ou comportement de ton objet métier, tu modifie le projet à 2 endroits différents dans deux langages différents.
pas plus que pour une appli web classique
>De plus, Microsoft, et Macromedia propose un système reposant sur une seul implémentation. J'espère que Mozilla, et Opera s'arrangeront aussi pour avoir qu'une seul implémentation...
Ah ba oui, reposer sur une techno propriétaire, c'est en effet plus facile d'avoir qu'une seule implementation, que quand on essaie de se reposer sur des technos standards, où il faut s'entendre avec tout le monde pour que ça fonctionne...
Oui mais faut voir les résultats aprés...
> Bref du bonheur.
tu l'as dit bouffi. mais renseigne toi un peu plus sur XUL. Je crois qu'il te manque quelques infos pour pouvoir faire une comparaison objective qui ne tourne pas au troll.
[^] # Re: hum ... XUL, CSS, SVG, ...
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é à 9.
permet moi d'en douter
>Tu pourras faire une interface graphique à peine plus complexe qu'avec du XHTML/CSS/EcmaScript.
ben voyons.
Un menu déroulant par exemple.
En xul : 2-3 balises à ta disposition.
En xhtml : 2-3 balises, + du code javascript dans tout les sens.
Désolé, mais il n'y a pas photo. On peut réaliser des interfaces VRAIMENT complexe avec XUL, sans que ce soit réèllement difficile.
> Mais si tu veux pouvoir réutiliser tes composants afin de les mettre à profit à d'autre endroit d'un projet. Tu ne pourra qu'en acquerant des compétences dans d'autre technologie et la tu te retrouves à te plonger dans la description: XPCOM , XBL, création de XPI.
euh... je ne vois pas ce que viennent faire XPCOM et XPI pour faire des composants graphiques réutilisables.
Dans le cas d'une appli web, tu n'as pas vraiment besoin de XPCOM ou XPI. Les traitements metiers se font toujours coté serveur web, en php java ou autre. Bref, ça ne change pas beaucoup de maintenant. Il y a juste l'interface qui change.
>Sans compter, les problèmes de déploiements de composants XPI du aux différentes versions de Mozilla.
oui mais ça, ça n'a rien à faire dans des applis web.
>A çà, tu rajoutes le développement du coté serveur dans un autre langage et tu te retrouves avec un beau mic-mac.
je ne vois pas en quoi c'est plus micmac que maintenant.
Une appli web actuellement, c'est quoi ?
HTML + CSS + JS + PHP/JAVA/autre
Une appli web en xul, c'est quoi ?
XUL (+XBL) + CSS +JS + PHP/JAVA/autre
où vois-tu que c'est plus le bordel ?
> Ou chaque développeur est irremplaçable car il n'y a que lui qui maitrise une technologies employé dans le projet.
tout développeur web maitrise un minimum HTML, CSS, JS, et PHP/JAVA/autre
Sous pretexte qu'on remplace le HTML par du XUL, il ne saurait plus rien faire ? ne saurait plus faire que du JS ou que du PHP ou... ???
>A çà, tu rajoutes toutes les parties codes qui vont être réecrite plusieurs fois. Par exemple, un objet métier et son comportement une fois en JavaScript côté client , une fois Php ou en Java côte serveur.
Ahh ? parce que pour toi, un objet metier fait parti de l'interface graphique ???? boudiou, tu as des méthodes de travail plutôt bordelique ! je comprend maintenant que tu t'en sort pas avec HTML +CSS +js + php/java/autre tout ensemble !
>ref, tu changes un attribut ou comportement de ton objet métier, tu modifie le projet à 2 endroits différents dans deux langages différents.
pas plus que pour une appli web classique
>De plus, Microsoft, et Macromedia propose un système reposant sur une seul implémentation. J'espère que Mozilla, et Opera s'arrangeront aussi pour avoir qu'une seul implémentation...
Ah ba oui, reposer sur une techno propriétaire, c'est en effet plus facile d'avoir qu'une seule implementation, que quand on essaie de se reposer sur des technos standards, où il faut s'entendre avec tout le monde pour que ça fonctionne...
Oui mais faut voir les résultats aprés...
> Bref du bonheur.
tu l'as dit bouffi. mais renseigne toi un peu plus sur XUL. Je crois qu'il te manque quelques infos pour pouvoir faire une comparaison objective qui ne tourne pas au troll.