Dites moi si je me trompe, l'objectifs de ses trois solutions est de répondre aux limites du HTML pour la construction d'IHM afin d'obtenir :
- des arbres
- des menus déroulants (sur plusieurs niveau)
- des afficheurs de graphes
- des textarea qui supporte (le gras, l'italique, le souligné, ...)
- des combobox éditable
- le support du Drag'n Drop
- gestion fine des événements sur les composants.
- D'autre composants graphiques plus évolué : Par exemple, un éditeur de graphe et dessin, un éditeur de tableau.
- de pouvoir réutiliser des composants graphique plus complexe basé sur des données métiers.
Arriver à faire tout çà sans que leur implémentation ressemble à une immonde bidouille
répartie sur trois langages XHTML, CSS, et JavaScript qui marchera
dans le meilleur des cas sur un navigateur et dont une partie de la logique
de l'IHM sera reporté côté serveur dans un autre langage.
Les 3 solutions réponde d'une manière différentes à ceux problèmes:
- Mozilla & maintenant Opera: Propose XUL,XBL, XPI, JavaScript , SVG, ... (J'en oublie)
Plein de nouveau langage à apprendre et peu de personne ayant déjà les compétences ou les bases nécessaire.
Pour développer, une pauvre application un peu plus complexe qu'un formulaire Web, il faudra acquérir la maîtrise de tous ces domaines techniques aussi complexe qu'inutile.
De plus, le risque qu'Opera et Mozilla n'est pas exactement la même implémentation.
- Macromedia: Flash, et son ActionScript. Technologie qui a fait ses preuves mais qui possède trois gros défauts à mon avis:
- Très propriétaires comme XAML mais là, c'est une techno très fermé qui nécessite de payé des licences pour communiquer avec un serveur d'application de manière simple.
- ActionScript n'est pas le meilleur langage que j'ai rencontré. Enfin, je crois que le gros problème provient de l'IDE.
- L'absence ou une faible réutilisabilité, il me semble (je suis pas un expert donc je me trompe peut être).
Néanmoins, il y a plein de personne sur le marché du travaille qui connaisse bien Flash et ActionScript et qui ont en général une bonne formation graphiste et en ergonomie de logiciel.
- Microsoft propose XAML: Langage intégrer à la plate-forme de .Net, on peut donc développer des composants aussi complexe que l'on souhaite dans le langage que souhaité, et lié les comportement de l'IHM dans le même langages. Et par un excès de fantaisie, on pourra même utiliser le même langage du côté serveurs !
Au final, il n'y aura que XAML à apprendre pour des développeurs un peu expérimentés dans les technos .Net !
Franchement, je n'aime pas Microsoft. Mais là dessus, çà sert à rien de se cacher les yeux. La communauté de Mozilla veut faire trop compliqué pour répondre à un besoin qui n'est en soit pas si compliqué que çà.
Sun et la communauté OpenSource de Java a déjà apporté toutes les briques nécessaires pour concurrencer
Microsoft sur ce terrains. Il y a plusieurs client riche (rich client) propriétaire, ou libre, utilisant Java
et la JVM comme plate-forme certains utilisent Web Start pour se déployer, et d'autre utilise simplement une applet.
Le langage de descriptions d'interface est quelques fois XUL ou un langage y ressemblant fortement.
Dans toutes les solutions que j'ai pu survolé le gros défaut à mon avis. C'est que la logique de l'IHM est souvent
réalisé par le biais d'un langage de script. Je n'ai jamais compris pourquoi il ne se contente
pas d'exécuter tout bêtement du bytecode Java provenant du serveur et exécuté dans une sandbox ? çà eviterai
d'avoir à réecrire, le code de la logique métier des objets du coté client.
L'autre gros défaut mais là je crois que c'est le même problèmes des trois autres solutions, il n'y a pas de framework « définissant »d'une manière rigoureuse les échanges de données entre le serveurs
d'applications, et le riche client.
Enfin, le dernier défaut est que personne ne parle d'eux.
Quelques liens d'exemple:
Propriétaires:
- http://www.bambookit.com/(...)
OpenSources:
http://luxor-xul.sourceforge.net/(...)
Journal Les rich clients XAML , XUL, Flash/ActionScript : une bataille gagné d'avance pour Microsoft.
8
juin
2004
# hum ... XUL, CSS, SVG, ...
Posté par ange_thom . Évalué à 9.
- elle repose sur des technos éprouvées, standards et connues (XML, CSS, SVG)
- elle est libre
- elle est multiplateforme : la où gecko tourne on peut utiliser cette techno bref sur beaucoup de plateformes
je ne vois pas en quoi il est plus dur d'apprendre XUL, XHTML, CSS et javascript que toute la structure .NET.
Ayant deja des connaissances en XHTML, CSS et XML je ne vois pas trop d'obstacles insurmontables pour apprendre XUL.
Par contre oui, il y a peu de comm sur XUL. Pourtant c'est une techno qui a deja quelques années.
Lors de Libr'East nous avions eu une conférence sur XUL et beaucoup de personnes qui ont assisté à cette conférence ont été charmés, reste à faire des sites, des applis et de la comm.
question bete : y a t il un XULforge ? un site regroupant des projets basés sur XUL.
[^] # Re: hum ... XUL, CSS, SVG, ...
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: hum ... XUL, CSS, SVG, ...
Posté par CoCoZ (site web personnel) . Évalué à 2.
Depuis quelques semaines je commence à avoir un peu de temps libre, et je l'utilise en partie pour me documenter sur xul parceque j'ai l'intention de m'y mettre serieusement.
[^] # Re: hum ... XUL, CSS, SVG, ...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
mince alors... j'avais des VIP et je ne le savais pas :-)
bon, sinon désolé si je t'ai endormi... (jamais facile de toute façon d'assister à une conf aprés déjeuner, et je ne suis pas le genre d'orateur qui sait reveiller les foules )
[^] # Re: hum ... XUL, CSS, SVG, ...
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 5.
Dans une conférence (je pense), les slides sont un support, mais l'orateur ne doit en aucun cas les lire, sinon c'est chiant. Il faut justement en rajouter, en dire beaucoup plus, développer. Ce n'était pas le cas ici.
Donc je pense qu'il faut encore améliorer tes conférences :)
[^] # Re: hum ... XUL, CSS, SVG, ...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
mais je n'avais absolument pas le temps de développer plus. 1 heure, c'était court pour montrer toutes ces technos...
[^] # Re: hum ... XUL, CSS, SVG, ...
Posté par pasBill pasGates . Évalué à 4.
Les slides ne servent vraiment a rien d'autre qu'indiquer les points importants, et tu es sense developper dessus, ils ne sont pas senses contenir tout ce que tu dis, sinon le resultat final c'est une audience qui dort pour les raisons invoquees par Fabien.
Bref, mets 3-4 points par slide grand maximum(juste les titres, par le developpement du sujet, des graphiques ca va aussi bien entendu), causes un peu dessus, mets ne te contente pas de lire le contenu du slide sans rien ajouter.
[^] # Re: hum ... XUL, CSS, SVG, ...
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: hum ... XUL, CSS, SVG, ...
Posté par Docteur_Canard . Évalué à 4.
http://mozdev.org(...) ?
(========>[])
[^] # Re: hum ... XUL, CSS, SVG, ...
Posté par syj . Évalué à 2.
Tu pourras faire une interface graphique à peine plus complexe qu'avec du XHTML/CSS/EcmaScript.
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.
Sans compter, les problèmes de déploiements de composants XPI du aux différentes versions de Mozilla. C sur tu peux faire plein de choses complexes mais tu ne pourras pas faire choses des simples rapidements.
A çà, tu rajoutes le développement du coté serveur dans un autre langage et tu te retrouves avec un beau mic-mac. Ou chaque développeur est irremplaçable car il n'y a que lui qui maitrise une technologies employé dans le projet.
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.
Bref, tu changes un attribut ou comportement de ton objet métier, tu modifie le projet à 2 endroits différents dans deux langages différents.
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...
Bref du bonheur.
A la question: "y a t il un XULforge ? un site regroupant des projets basés sur XUL. "
Pour XUL, j'ai ces liens :
http://www.xulfr.org/(...)
http://www.xulplanet.com/(...)
[^] # Re: hum ... XUL, CSS, SVG, ...
Posté par Black Fox . Évalué à 4.
Pour l'échange client serveur je fais ça en XML-RPC (Même si j'ai du débugger à la Mano le compo XML-RPC de Mozilla et Firefox qui empéchat toute utilisation serieuse, faut que je l'envoie sur le bugzilla de moz celui là)
Pour les XPI c'est réservé aux applis s'installant sur le DD, principalement les extentions du navigateur, ce qui ne devrait pas exister avec le XAML donc Mozilla n'as rien à perdre de ce coté là (Mon appli s'accède comme un appli web standard, avec la seule différence qu'elle utilise des contrôle nomaux (Arbre, ...)
[^] # Re: hum ... XUL, CSS, SVG, ...
Posté par syj . Évalué à 1.
[^] # Re: hum ... XUL, CSS, SVG, ...
Posté par Black Fox . Évalué à 2.
[^] # Re: hum ... XUL, CSS, SVG, ...
Posté par Laurent J (site web personnel, Mastodon) . É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.
[^] # Re: hum ... XUL, CSS, SVG, ...
Posté par Médéric RIBREUX (site web personnel) . Évalué à 3.
Dans mon boulot j'ai commencé à développer des petites applis pour l'intranet (tout le monde est sous Mozilla !) qui permettent de naviguer plus facilement sans avoir à rafraichir ou à cliquer n fois sur des contrôles identiques (ex: un menu sous forme de Tree pour un site sous SPIP).
J'ai consacré à peine une journée à m'autoformer à XUL et le tour est joué: j'ai répondu à la majorité de mes besoins. En peu de temps, on arrive à créer une IHM réactive sans écrire 3000 lignes de codes qui gèrent tout.
Le reproche que je peux faire à XUL, c'est la complexité à communiquer avec des services. Néanmoins, pour ces problèmes, quelques lignes de PHP qui génèrent du XUL m'ont permis d'arriver à un niveau satisfaisant. Je n'ai pas eu le courage de me lancer dans du XML-RPC, ni du SOAP.
D'une manière générale, pour les quelques développements que j'ai eu à réaliser ces derniers temps, XUL m'a fait gagner pas mal de temps en proposant des contrôles assez riches (celui que j'ai le plus utilisé est le Tree). En plus de ça, je développe uniquement sous Linux (ma station d'admin l'impose) et j'ai besoin d'avoir de quoi tester le résultat (clients sous win2k). Donc, hors de Mozilla, point de salut !
# Petit problème...
Posté par ploum (site web personnel, Mastodon) . Évalué à 7.
1) Il n'est pas encore sorti ni prêt de sortir (encore quelques années)
2) Il ne sera disponible que pour un faible partie de la population.
Sinon, je m'insurge contre ta phrase qui parle des graphistes ergonomes qui connaissent le flash.
Justement, les graphistes arrivent à faire des trucs jolis en flash mais complètement inutilisable !
Je crois que, quoiqu'il en soit, ce n'est pas la qualité d'un produit qui le fait réussir mais simplement le marketing qui va avec.
Si on pousse XUL à grop coup de Marketing et de un ou deux sites visibles utilisant XUL, et bien XUL a de grandes chances de s'imposer.
(par exemple si amazon adopte officiellement une interface telle que celle développée en XUL (google XUL amazon) )
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Petit problème...
Posté par Pinaraf . Évalué à 2.
C'est vrai quoi, les pubs sont toujours horrible et c'est les seuls flash que je subisse ! Flash a le malheur aussi de nécessiter un plugin avec une licence tordue sous linux...
[^] # Re: Petit problème...
Posté par Guillaume Knispel . Évalué à 2.
[^] # Re: Petit problème...
Posté par syj . Évalué à 1.
> 1) Il n'est pas encore sorti ni prêt de sortir (encore quelques années)
> 2) Il ne sera disponible que pour un faible partie de la population.
Néanmoins, XUL et les technos associés ne se sont pas non plus imposé en dehors de Mozilla ou de gecko alors que ce sont des technologies qui se sont utilisés depuis de nombreuse années.
A mon avis, çà vient justement du fait qu'il ne reponde pas au besoin. Je pense qu'il manque à cette techno le framework qui la rendra facile à utiliser et à integrer dans des applications web.
Au passage développer programme qui te créer des interfaces graphiques à partir d'un fichier XML n'est pas très dur.
De plus avec les langages modernes (supportant la reflexivité) , ajouter un langage de scripts gérant la logique applicative çà ne l'est pas bcp plus. Il n'y a qu'a regarder le code luxor. Je ne pense pas que XAML mettra temps de temps que çà a sortir. L'avenir nous le dira.
>Sinon, je m'insurge contre ta phrase qui parle des graphistes >ergonomes qui connaissent le flash.
>Justement, les graphistes arrivent à faire des trucs jolis en flash >mais complètement inutilisable !
Je suis peut être optimiste sur ce point ;-) Néanmoins reconnait qu'il y a bcp plus de personne maitrisant Flash et ActionScript que dans les technos de Mozilla.
[^] # Re: Petit problème...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
hum...
Si XUL n'est pas si connu, c'est tout simplement à cause de la politique de mozilla.org, nullement le fait que cela ne répondent pas au besoin.
Les developpeurs de mozilla.org n'ont pensé pendant des années qu'à developper XUL uniquement dans l'optique de faire leur browser. Et en aucun cas dans l'optique de pouvoir faire d'autres applis avec.
Cela ne fait que quelques mois qu'ils commencent à comprendre que les technos qu'ils ont développé ont un potentiel énorme, en dehors de leur browser.
> Néanmoins reconnait qu'il y a bcp plus de personne maitrisant Flash et ActionScript que dans les technos de Mozilla.
c'est juste une histoire de marketing.
[^] # Re: Petit problème...
Posté par Mouns (site web personnel) . Évalué à 1.
XUL reste encore en dev meme si c a peu pres stable, et pour faire un composant XUL, faut se taper du C. "à peu pres stable" genre un moz ouvert et un apt-get qui met a jour chrome:/// et c la cata, si XUL avait une gestion poussée des dependances et des versions, ce probleme serait simple a resoudre ... mais ce n'est pas facile, car il faut reecrire XUL de bout en bout. tant que chaque fois que je change un truc il faille relancer moz ( et encore je me souviens de l'epoque ou il fallait en recompiler une partie ), je ne recommanderai pas professionnellement le XUL. donc XUL c "cool".
XAML et la WinFS ( deja repoussé ) vont ils rejoindre le record du plus long vaporware detenu par MS ? MS-DOS 4.0 devait etre multitache à sa sortie dixit les annonces presses de MS à l'époque.
[^] # Re: Petit problème...
Posté par syj . Évalué à 2.
J'ai fait très peu de flash mais si je me rapelle bien.Il y a des champs texte, simple ligne et multiligne, des combobox, des radiobuttons, je crois même des champs type RTF (à vérifier pour ce dernier).
J'avais essayer de répondre aux problèmes que j'ai soulevé dans le journal avec Flash. Mais au final, çà devenait trop compliqué pour réaliser notre application sans avoir à payer les licences pour les serveur des composants J2EE de Macromedia.
çà revenait à écrire une méthode pour soumettre l'equivalent d'un formulaire. Bref j'ai rapidement abandonné, mais je n'ai peut être pas choisi la bonne piste ou pas assez longtemps perseveré.
[^] # Re: Petit problème...
Posté par Mouns (site web personnel) . Évalué à 3.
pour info, un document SWF commence par une signature sur 3 octets puis un octet de version, 4 octets pour la taille du fichier, un "RECT" pour decrire la taille du film, 2 octets pour le frame rate, et enfin 2 octets pour le nombre de frames dans le film.
pour les boutons en flash ils sont definit par des "DefineButton*" et decrit par des "ButtonRecord" decrivant chacun des etats possibles ( up / over / down / hit ) et des etats transitoires existent pour les animations.
le champ de type RTF n'est rien de plus qu'un parser RTF qui rend le document avec des "DefineFont" et des "DefineText" ( qui associe chaque caractere avec des contrainte de rendu sur les glyphes defini avec "DefineFont" ).
apres faire du flash dynamique revient simplement à charger ( "GetURL*" ) du swf compilé à la volé par un serveur distant moyennant arguments passés. si vous avez deja programmé une HP, le principe de programmation flash vous semblera agréablement similaire.
donc, je maintiens ce que j'ai dit : flash sert a faire de l'animation vectorielle. maintenant, rien ne t'empeche d'en faire autre chose.
[^] # Re: Petit problème...
Posté par pasBill pasGates . Évalué à 2.
2) Le truc avec les ventes de MS, c'est que "une faible partie de la population", disons les gens ayant achete Longhorn dans les 5-6 premiers mois, ca fait deaj bcp plus que tout le marche Linux desktop reuni.
5% du marche desktop Windows c'est bcp plus que 100% du marche desktop Linux, et ca ca compte.
# XUL...
Posté par Pinaraf . Évalué à 4.
Plein de nouveau langage à apprendre et peu de personne ayant déjà les compétences ou les bases nécessaire.
Pour développer, une pauvre application un peu plus complexe qu'un formulaire Web, il faudra acquérir la maîtrise de tous ces domaines techniques aussi complexe qu'inutile.
De plus, le risque qu'Opera et Mozilla n'est pas exactement la même implémentation.
Où as-tu lu qu'Opéra allait proposer XUL ???
Pour faire une appli sophistiquée en XUL, pas de pb : XULMaker (Mozilla 1.4 maximum, je sais pas pour la version CVS...) est un dessinateur cliquodromesque.
Javascript : un webmestre se doit de connaître, non ? Et puis là encore les outils mozilla sont puissants !
XPI sert à installer des extensions, XBL sert à créer des nouveaux composants (houla j'ai des doutes !)
Tu dis que XUL est compliqué : c'est FAUX !!! XUL est vachement simple, j'attend juste le "kit" des balises pour quanta ou un autre éditeur du même topo...
(ps : http://sharewebnom.sf.net/notes/test.html(...) avec mozilla : la transparence fait ramer mais ça passe)
Quant au XAML, attendons qu'il sorte !!! Je doute qu'il soit aussi cool qu'il en a l'air... Déjà faudra l'EDI parce que les extraits de code que j'en ai vu, dès qu'il y a du vectoriel faut s'accrocher (remarque SVG c'est pareil) !
[^] # Re: XUL...
Posté par syj . Évalué à 0.
Effectivement, tu fais bien de le signaler. j'ai relu le papier publier par Opera et Mozilla. XUL n'en fait pas partie.
>Pour faire une appli sophistiquée en XUL, pas de pb : XULMaker >(Mozilla 1.4 maximum, je sais pas pour la version CVS...) est un >dessinateur cliquodromesque.
>Javascript : un webmestre se doit de connaître, non ? Et puis là >encore les outils mozilla sont puissants !
>XPI sert à installer des extensions, XBL sert à créer des nouveaux >composants (houla j'ai des doutes !)
>Tu dis que XUL est compliqué : c'est FAUX !!! XUL est vachement >simple, j'attend juste le "kit" des balises pour quanta ou un autre >éditeur du même topo...
XUL est vachement simple pour décrire une interface graphique mais est ce que XUL te permet de faire communiquer avec le serveur Web sans avoir à écrire un grand quantité de JavaScript ? Car tu le reconnaitra une application qui tourne uniquement dans ton navigateur n'a pas grand interêt.
[^] # Re: XUL...
Posté par Pinaraf . Évalué à 2.
Marche très très bien, est rapide, te permet rapidement de parser le flux XML renvoyé par le serveur (par exemple)...
C'est du javascript mais c'est vraiment simple... (merci au Venkman Debugger, le meilleur assistant au javascript sous mozilla !)
[^] # Re: XUL...
Posté par syj . É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.
[^] # Re: XUL...
Posté par Pinaraf . Évalué à 1.
> 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 ?
Non quoique si, tu peux construire ton XML au fur et à mesure des saisies grâce à des évènements Javascript.
>Dans un autre langage, tu effectuera la même opération côté serveur.
Ben faire des récupérations de données en PHP c'est tellement simple... Ça change rien.
> 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.
Tu me fournis le serveur nécessaire ? Hé oui, le même des 2 côtés signifie un serveur MS => cher !!! (à mon goût uniquement ?)
> Je l'utilise en dernier recours car il plante tout le temps chez moi dès que
> j'ai trop d'onglet d'ouvert.
J'utilise la suite mozilla complète pour faire du dév, et konqueror pour naviguer, comme ça j'ai un mozilla clean...
[^] # Re: XUL...
Posté par Laurent J (site web personnel, Mastodon) . É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...
[^] # Re: XUL...
Posté par syj . Évalué à 2.
Au passage l'arrogance ne prouve rien, si ce n'est un excès d'ego.
... Mais là, je dois reconnaitre que tu as raison sur certain point.
En cherchant un tutoriel sur SOAP et XUL, je suis tombé sur cette page expliquant comment utilisé une source RDF pour renseigner une liste.
http://xulfr.org/wiki/ApplisWeb/ExemplePhpRdf(...)
L'affection des valeurs dans la widget Tree se fait par un DataSource issue de la requête sur une source RDF. Je suppose que l'utilisation d'un service web est similaire enfin j'ai eu beau chercher, je n'en ai pas trouvé.
J'admets que la méthode semble assez élegante.
[^] # Re: XUL...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Non, mais c'est un peu énervant d'avoir des gens comme toi qui critique quelque chose sans rien y connaître.
>Au fait, tu fais quoi exactement comme projet avec XUL ?
J'ai fais quelques applis web confidentielle en xul.
sinon matte http://xulfr.org..(...) "LaurentJ" te diras peut être kkchose ;-)
Et si tu es suffisement de temps, tu trouveras mon site avec mon cv..
> J'admets que la méthode semble assez élegante.
;-)
[^] # Re: XUL...
Posté par real_pouet . Évalué à 0.
Pour faire une appli sophistiquée en XUL, pas de pb : XULMaker (Mozilla 1.4 maximum, je sais pas pour la version CVS...) est un dessinateur cliquodromesque.
c est un troll?
tu as deja utilise xulmaker?
ou alors il a fait de * tres gros * progres depuis 10 mois.
--
pouet
# Choix vs. solution intégrée
Posté par Sol Weintraub . Évalué à 6.
Dans le bazar de l'Opensource, les idées fusent dans tous les sens, et la cohérence ne nait que lorsque des acteurs majeurs décident de s'associer, ou lorsqu'il s'agit vraiment de l'objectif d'un projet (GNOME, KDE). Ce système peut avoir l'air de pécher par certains points, et c'est la cas lorsque l'on parle ici par exemple d'industrialisation de procédés comme XUL. Mais il permet de satisfaire également beaucoup de monde en proposant des technologies étranges ou marginales. Il permet aussi de déployer des solutions là où installer l'ensemble du code Microsoft serait embêtant pour des questions techniques ou de coût.
Pour finir, XAML n'est effectivement pas sorti et la moitié des nouvelles qu'on peut lire sur le sujet sont des messages d'illuminés d'un bord ou de l'autre. Il est important au monde OpenSource d'apporter une alternative ou une réimplémentation, parce que c'est son rôle. Opéra et les projets GNOME et Mozilla s'y sont penchés, c'est très bien. Si d'autres souhaitent se pencher sur le sujet d'une façon encore différente, c'est encore mieux. Attendons maintenant quelques temps de voir l'évolution de toutes ces idées.
# hu ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
d'avoir à réecrire, le code de la logique métier des objets du coté client.
tout simplement parce que la logique metier, elle n'a rien à faire dans la couche "presentation", coté interface quoi...
Faut pas tout mélanger... Si les méthodes de conception en sont arrivé à séparer en couche les différentes parties d'une applis, ce n'est pas pour rien.
Quant à executer du bytecode java provenant du serveur, ça existe déjà depuis des lustres, ça s'appelle des applets. Peut être en étudiant le résultat de l'épopée de cette techno, tu comprendra pourquoi on n'utilise plus du bytecode java coté client.
> La communauté de Mozilla veut faire trop compliqué pour répondre à un besoin qui n'est en soit pas si compliqué que çà.
je te propose de t'informer plus sur le pourquoi du comment, notament, historiquement, pourquoi Mozilla a inventé XUL et co, et pour quel usage...
[^] # Re: hu ?
Posté par syj . Évalué à 1.
>d'avoir à réecrire, le code de la logique métier des objets du coté >client.
çà depend, l'interêt d'un client rich peut être d'avoir une architecture semi-connecté.
Dans ce cas, il est bien utile d'avoir ta logique métier reporté du coté client.
[^] # Re: hu ?
Posté par Pierre Tramonson . Évalué à 2.
On paie nos impôts en ligne avec ça...
C'est pas parfait (surtout les droits d'accès), mais ca a le mérite d'exister.
A quand la même chose en XUL ? :)
[^] # Re: hu ?
Posté par syj . Évalué à 1.
http://www.fr.map24.com/(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.