AjaxWrite
Par Laurentj le jeudi, mars 23 2006, 09:59 - Technologies Web - Lien permanent
- Quelques balises XUL pour l'interface, histoire d'éviter de se trainer des tonnes de scripts JS pour faire des widgets et éviter donc d'avoir des widgets, pauvrement accessible, qui ressemblent de loin par temps de brouillard à ce que l'utilisateur à l'habitude d'utiliser dans des applications "normales".
- un peu de xmlhttprequest pour envoyer ou reçevoir le document édité à partir du serveur
- quelques scripts coté serveur pour réaliser la convertion du document que vous voulez éditer vers HTML (ou à partir de HTML pour la sauvegarde)
- un peu de javascript pour programmer les quelques traitements sur les actions de l'utilisateur
Et vous obtenez un traitement de texte en ligne : AjaxWrite.
Certains y verront un éditeur simpliste mais ce n'est qu'un début.
Et n'en doutez pas, on va voir débarquer de plus en plus d'applications online en XUL. Pour les développeurs, XUL facilite beaucoup les choses pour la réalisation d'interface utilisateur.
Et cela apporte aussi énormément de souplesse !
Un exemple : imaginez que dans AjaxWrite, on puisse indiquer l'url d'un overlay XUL (url qui serait stockée dans un cookie). (Pour rappel, un overlay est un fichier XUL qui indique des éléments XUL à ajouter à une interface déjà définie. C'est le coeur même du système d'extension de Firefox.)
Bref, on indiquerait cet overlay, et hop : vous rajoutez ainsi vos propres fonctionnalités à une application distante, sans avoir à modifier les sources sur le serveur ! (et sans rien à installer en local). Si c'est pas du "Web 2.0" ça ... 
Bref, XUL, c'est TOTALEMENT DEMONIAQUE !!
Les applis en HTML, ce n'est pas l'avenir. Moi j'vous l'dit ! (Surtout quand XUL sera normalisé par le W3C).
PS: ah ! On me souffle dans mon oreillette que l'auteur de AjaxWrite trouve trés bonne mon idée de pouvoir indiquer ses overlays dans l'application... 
PS2: Tiens, et pourquoi pas réaliser une extension pour Firefox, qui permettrait d'indiquer les overlays à ajouter à telle ou telle application web quand on les utilise, même quand cette fonctionnalité n'est pas explicitement prévue par leurs auteurs ? À étudier...
Commentaires
"ajaxWrite is a streamlined word processor, comparable to Microsoft Word" le gars il a du confondre avec WordPad ^^
que ce soit en javascript+html ou en xul+javascript je ne comprend pas trop le besoin d'avoir un wordPad en ligne, c'est lent, lourd pas très performant bref c'est typiquement le style d'appli qui doit être locale.
bref tout comme le "web 2.0" le "client riche" est parfois aussi une belle tarte à la crême ou sous pretexte de "modernitude" on nous vend du plomb pour de l'or en barre ^^
XUL rules!
Je trouve dommage que l'application contienne le mot "Ajax", mais ca doit etre dans l'air du temps, tant pis... (je trouve ce nom vaseux et condescendant...là voila je l'ai dis...)
Roland, Raoul : tout à fait d'accord.
Je voulais juste montrer par ce billet les possibilités de XUL.
(juste en passant: profitez en! google ne connaît pas ajaxwrite. Pour une fois on en connaît plus que google;-) http://www.google.fr/search?q=ajaxWrite fin de la parenthèse ==> )
Je ne vois pas trop l'intérêt d'utiliser le format word. On ne fait que effectuer des conversions Word <-> HTML tout le temps.
apparté, mais si google sait tout sur tout : http://groups.google.fr/groups?q=ajaxWrite&sa=N&tab=wg
Et oui... apparté ment
Laurent: Je partage les opinions de Roland et Raoul. Mais je trouve aussi que XUL a des potentiels fabuleux.
Penses-tu que ce genre d'applications pourraient être réalisées localement. En gros développer des applications XUL qui à l'occasion peuvent se connecter à une URI, mais qui surtout qui permettent d'utiliser un moteur local.
Imaginons par exemple un gestionnaire de photos ala Flickr en XUL mais sur ton espace disque local avec une possibilité de synchroniser *certaines* (ACL) sur un disque distant (serveurs) pour qu'elles soient visibles par d'autres et de synchroniser dans le sens contraire les commentaires partagées sur les photos en local.
Karl : oui tout à fait.
On peut imaginer par exemple fournir l'application sous forme d'extension (ou de paquet utilisable directement par xulrunner). Parce que l'application est installée en local, on peut alors accéder au disque local, gerer du drag'n'drop inter-application etc...
Par contre, pour la synchro, il n'y a rien de prevu qui faciliterait la chose. Donc faut coder ça "à la main". Mais ce n'est pas forcément difficile à faire. Un petit coup de xmlhttprequest...
et XMLHTTPRequest va avoir son premier draft publié bientôt
Merci pour l'info à propos de XUL.
(Ce serait peut-être bien que Dotclear puisse produire des identifiants pour chaque élément div, p, etc. ? là, ça m'aurait par exemple permis de diriger directement sur le bon paragraphe.)
(J'ai ajouté un point-virgule après les premiers guillements dans les titres des liens, sinon ça donnait un " dans la bulle.)
hmmm… c'est là où je pense que l'on est en voie de régression, Bertrand.
Les navigateurs en termes d'UI et surtout d'éditions sont très pauvres et ne permettront pas de faire beaucoup de choses.
En revanche cela pose une question beaucoup plus intéressante. Est-ce que les traitements de texte avec des millions de fonctionnalités ne sont ils pas trop chargés en fonctionnalités ?
Je pense qu'il y a surement une réponse qui se situe entre les deux. Le jour où le chef d'entreprise ne pourra pas travailler sur ces documents car le serveur où ses documents sont hébergés est innaccessible… peut-être changera t il de discours. Ce que nous enseigne le Web, c'est que l'on peut faire des interactions entre différentes applis, qu'un langage d'interface comme XUL peut être pratique pour le faire, que le navigateur soit la nouvelle UI à tout faire, pourquoi pas, mais pas vraiment tel qu'il est maintenant.
Par exemple, ce même commentaire est tapé dans une interface pauvre.
En gros cela me rappelle, une technologie passionnante OpenDoc qui a avait été implémenté sur le mac il y a bien longtemps où les fonctionnalités étaient utilisables cross-applications.
Pour IE, difficile de ne pas être d'accord avec toi. Cependant, mettre ainsi tous les navigateurs dans le même panier m'étonne de ta part. XUL n'est-il pas là, justement, pour faire en sorte que des progressions soient possibles ? Le "problème", me semble-t-il, réside plutôt dans le manque d'informations auxquelles ont accès les utilisateurs sur ces questions, mais je suis sûr que beaucoup vont se mettre au XUL, comme on a pu le voir avec PHP par exemple, et vu les premiers échos sur IE7, ça promet des migrations vers Firefox.
Des millions de fonctionnalités, ça me paraît beaucoup ;-) ; si jamais tu considères la quantité absolue de fonctionnalités (nombre de logiciels installés*nombre de fonctionnalités par logiciel), alors là, oui, ça en fait un paquet (et très peu sont employées dans les faits). Lorsque j'utilise ScrapBook, je vois ce que m'apporte XUL. (J'ai beau être sérieux en écrivant ça, cette dernière phrase, qui se trouve quelque part entre la méditation zen et la publicité pour lessive, me fait tout de même sourire.) Je trouve que cet AjaxWrite (bien qu'encore un petit peu trop compliqué pour une utilisation vraiment instinctive - notamment en ce qui concerne les tableaux et les listes), pour des logiciels comme Dotclear ou SPIP, par exemple, est une petite merveille.
ça, c'est le choix de Laurent (et t'es quand même difficile, il a fait beaucoup d'efforts sur ce point par rapport à la majorité :-). D'ailleurs, t'avais pas teasé quelque part au sujet d'un espace de commentaires sur la-grange ? )
J'ai pas trouvé le système qui me ferait penser à le faire. D'ailleurs c'est un phénomène intéressant, nulle part je n'ai vu d'applications de gestion de commentaires indépendantes.
Lorsque tu as écrit au sujet d'une régression, je me suis dit : "citer Loïc Le Meur, c'est peut-être cela dont il parle ?" ; et puis en retrouvant ceci, j'ai rencontré cela :
Quelques liens en relation avec ce billet et ses commentaires :
cacaaaa
trop dur xul
bah ffff faut des objectifs... le web ça sert à rien... moins c bien mieux c'est... hop
on n'est pas des vendeurs de colifichets nous...
/me sort