Sondage AJAX

Posté par  .
Étiquettes : aucune
0
8
juin
2006
  • c'est quoi ce truc ? :
    361
    (11.1 %)
  • je compte m'y mettre :
    387
    (11.9 %)
  • je suis en train d'apprendre :
    142
    (4.4 %)
  • testé et approuvé :
    406
    (12.5 %)
  • testé et désapprouvé :
    69
    (2.1 %)
  • une mode sans intérêt :
    223
    (6.8 %)
  • je suis déja passé au web 3.0 coco... :
    284
    (8.7 %)
  • je lave ma salle de bain avec :
    1126
    (34.6 %)
  • vive le foot ! :
    260
    (8.0 %)

Total : 3258 votes

La liste des options proposées est volontairement limitée : tout l’intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées ou de l’impossibilité de choisir plusieurs réponses. 76,78 % des personnes sondées estiment que ces sondages sont ineptes.

  • # Un gros buzz

    Posté par  (site web personnel) . Évalué à 8.

    La technique existait bien avant le mot et beaucoup d'applis qu'on nous présente comme ajax existaient déjà aussi.

    Son seul intérêt est de rendre populaire auprès des développeurs le javascript comme langage de programmation.

    • [^] # Re: Un gros buzz

      Posté par  . Évalué à 0.

      En effet,

      C'est une technique relativement impressionnante, mais qu'il faut utiliser avec précaution!

      Un site totalement en Ajax, c'est laid (et non référencé) mais sa augmente tout de même la convivialité dans certain cas.

      [x] testé et Approuvé mais sous condition :)

      wako

      • [^] # Re: Un gros buzz

        Posté par  . Évalué à -1.

        non référencé ?
        le nouveau crawler de gogol possède un interpréteur javascript ...

    • [^] # Re: Un gros buzz

      Posté par  . Évalué à 0.

      Son seul intérêt est de rendre populaire auprès des développeurs le javascript comme langage de programmation
      Je ne suis pas complètement d'accord. Pour un développeur PHP-JavaScript-HTML, ca rend de précieux services. Et ca répond à un besoin qui existe depuis longtemps.

      J'admets que Java aurait certainement fait l'affaire pour ce genre de problématique mais niveau déploiement et stratégie d'entreprise de création de "progiciels", la démarche et les objectifs sont différents, notamment en termes de (pardonnez l'anglicisme) time-to-market. Et quand on développe une application qui a déjà plusieurs années-hommes derrière elle, c'est pas tous les jours qu'on remet en cause la technologie (langage de programmation choisi) et qu'on reconstruit tout.

      • [^] # Re: Un gros buzz

        Posté par  (Mastodon) . Évalué à 6.

        Quelle différence fondamentale y a-t-il entre "Ajax" et "PHP+javascript+HTML/CSS" ?
        Le monsieur te disais que ces trucs là existaient avant la création du buzzword "Ajax", et que ce buzzword sert surtout à populariser la méthode.

        "Ajax" ne répond pas à un besoin, ça met un nom sur une solution vieille comme le javascript...
        Mais oui, le javascript répond à un besoin, c'est sûr :)

        Yth.

        • [^] # Re: Un gros buzz

          Posté par  . Évalué à 5.

          Euh, le côté asynchrone de la techno, qui permet de rafraîchir une partie seulement du formulaire, je ne crois pas l'avoir déjà vue auparavant... Ou plus exactement, je l'ai vu apparaître il y a quelques années, lorsque MS a créé l'objet JS en question ...

          • [^] # Re: Un gros buzz

            Posté par  (site web personnel) . Évalué à 1.

            Ce n'est pas parceque tu ne l'avait pas vu avant, qu'il n'existait pas d'autres techniques.

            Il y a quelques annees, j'avais fait une recherche sur les methodes permetant de faire la meme chose qu'Ajax. Et j'en avais trouve plusieurs.
            A l'epoque il fallait rechercher le terme "remote scripting".

            Voila quelques methodes que j'avais trouve a l'epoque :

            La premiere methode consistait a utiliser une "iframe" (ou frame) cachee dans la page. Il suffisait de changer la source de l'iframe pour une url contenant les parametres voulus. Une fois la source de la frame chargee, un JS se lancait automatiquement pour metre a jour la page principale. (Des variantes de cette methodes consistaient a creer l'iframe a la volee, ou a creer, via dom, un "tag script" dans le head de la page poura aller "lancer le script".)

            Une autre methode consistait a utilsier la communication Javascript <-> Java, via l'objet "LiveConnect" de Netscape (introduit avec Netscape 4 si je m'abuse). A ce moment on utilisait un applet Java servant de pont. La page demandait a l'applet de contacter le serveur. C'est ensuite l'applet qui recevait la reponse et en informait la page web.

            La derniere methode, consistait a utiliser une image d'un pixel et les cookies. Le principe, on change la source d'une image. Des que cette derniere est chargee (ou non), on consulte le contenu d'un certain contenu. Ce cookie contient la reponse a notre requete. Il fallait utilsier les cookies, car il n'etait pas possible de lire "l'image".


            Pour conclure je rejoindrais ceux qui disent qu'Ajax n'est qu'un "Buzzword". Les techniques existaient deja (depuis longtemps pour certaines). On commence de plus en plus avoir le mot Ajax un peu partout, c'est la nouvelle mode. On a meme l'impression que c'est "in" de le metre a toutes les sauces.

            Je finirais par une petite anecdote. J'ai vu une news sur Digg qui presentait un site "Ajax" qui permetait de choisir une charte graphique a partir d'une couleur. Le seul hic, etait que dans le site il n'y avait pas de "Ajax", ce n'etait qu'un site utilisant du bete Javascript ...

            • [^] # Re: Un gros buzz

              Posté par  . Évalué à 1.

              une news sur Digg qui presentait un site "Ajax" qui permetait de choisir une charte graphique a partir d'une couleur. Le seul hic, etait que dans le site il n'y avait pas de "Ajax", ce n'etait qu'un site utilisant du bete Javascript ...
              On dirait plutôt du CSS/DHTML.

              La premiere methode...
              Une autre methode...
              La derniere methode...
              je rejoindrais ceux qui disent qu'Ajax n'est qu'un "Buzzword". Les techniques existaient deja (depuis longtemps pour certaines)
              Comme déjà expliqué ci-dessous et ci-dessus, oui, il y avait d'autres techniques. Dans ce cas, comprends que c'était des techniques et non pas les techniques! Et comme expliqué ci-dessous, ces techniques impliquaient la mixité de langages (surtout si tu rajoutes une couches de Java dans du PHP/JavaScript) ou pire : l'utilisation des cookies, ou le travestissement du tag en conteneur de données. C'était donc du bricolage. Comme pour mettre un tableau dans ton salon, tu peux le poser sur des parpaings (c'est laid, ca bouffe de la place, et tu vas devoir faire très attention le jour où tu bouges tes meubles) ou mettre un clou et une corde (c'est simple, propre, et sûr).

        • [^] # Re: Un gros buzz

          Posté par  . Évalué à 7.

          La différence fondamentale est que JavaScript s'exécute du côté client, PHP du côté serveur. Ainsi pour aller chercher des données à distance, il fallait exécuter un nouveau script PHP (déclenché par un événement JavaScript) puis transmettre les données en JavaScript depuis la frame susnommée vers la page principale (parent).

          C'est quelque chose que j'ai déjà fait, et c'était une solution lourde à mettre en place, et lourde à maintenir. Mes connaissances en Ajax sont encore limitées mais il me semble que les mécanismes sont différents (donc ce n'est pas un nouveau nom sur une vieille solution) et ca me parait vachement plus propre que d'utiliser le langage X pour appeler le langage Y et refournir les donnés à X qui va se passer la balle à lui même en remontant au parent.

      • [^] # Re: Un gros buzz

        Posté par  . Évalué à -1.

        Foutaises !

        • [^] # Re: Un gros buzz

          Posté par  . Évalué à 8.

          Le business loto ça laisse des traces que même Ajax n'efface pas...

  • # Une technologie révolutionnaire !

    Posté par  . Évalué à 7.

    Je vais profiter de cette opportunité qu'est ce sondage pour vous faire partager mon expérience professionnelle dans ce domaine.

    Je travaille à la DSI d'une société composée de plus de 5000 collaborateurs. La mobilité étant l'un des points clés de notre fonctionnement, nous avons besoin d'un système d'information consultable depuis des locations distantes et variables. Etant donné ces contraintes, l'utilisation de web-services dans notre applicatif métier s'imposait.

    Notre ancien système utilisait déjà les services web et en particulier la technologie ActiveX qui était innovante en son temps. Cependant, l'usage a fini par montrer les limites, en particulier au niveau de la sécurité et de l'interopérabilité. Il y a 3 ans, nous avons donc décidé la refonte totale de notre système d'information en utilisant des technologies plus adaptées. Après une phase de veille technologique de 18 mois composée de réunions bimestrielles entre les acteurs du département, nous avons adopté une approche Web 2.0, qui ne portait pas encore ce nom. Parmi les lignes principales, elle suggérait l'utilisation d'AJAX du côté du poste client. En effet, nous voulions à la fois éviter d'installer des modules supplémentaires et ainsi augmenter les coûts d'exploitation tout en nous affranchissant des possibilités plus que limitées qu'offre le HTML en matière d'interface graphique.

    Un test pilote a été réalité en migrant en premier lieu notre CRM (seule la partie cliente a été changée, notre progiciel ne communiquant que par notre serveur J2EE au travers d'un EAI). Après des essais concluants, nous avons poursuivi en migrant petit à petit notre ERP et toutes nos autres applications maison.

    Après plusieurs mois d'utilisation, le bilan est nettement positif. Non seulement nous avons obtenu un TCO avantageux, mais nous avons également fortement réduit la TMA, ce qui en cette période de restrictions budgétaires s'avère plus qu'opportun. Nous avons également noté une amélioration sensible de la productivité de nos collaborateurs qui sont plus que satisfait de l'ergonomie et de l'accessibilité de nos applications. L'utilisation d'une technologie standard et interopérable comme AJAX nous a également permis de nous affranchir du poste client. Ainsi, un collaborateur peut accéder au système d'informations aussi bien depuis un poste fixe qu'un PDA ou un téléphone portable.

    Pour conclure, je dirais qu'AJAX est au web ce que le nucléaire est à l'énergie : une révolution technologique. Je table que d'ici 10 ans, 90 % du web sera passé à AJAX.

    • [^] # Re: Une technologie révolutionnaire !

      Posté par  . Évalué à 10.

      FOUTAISES !

    • [^] # Re: Une technologie révolutionnaire !

      Posté par  . Évalué à 4.

      Pierre Tramo, cet être étrange venu d'ailleurs, existerait-il donc vraiment?

    • [^] # Re: Une technologie révolutionnaire !

      Posté par  (site web personnel) . Évalué à 7.

      "Je table que d'ici 10 ans, 90 % du web sera passé à AJAX."

      C'est du propre!

    • [^] # Re: Une technologie révolutionnaire !

      Posté par  . Évalué à 5.

      Ferrais-ti parti de ce consultants qui prenne leur metier au sérieux ?

      Aurrais-tu fais une école de commerce ?

      J'ai du mal a identifier la source de ton verbiage aussi vide qu'ajax...

      Pour toi dans 10 ans 90% du web sera de l'ajax ? Mais de quoi tu parles. Ajax c'est un récipiant vide. même gmail n'a rien inventé. Ils ont juste travaillé dur avec de l'existant.

      Par contre si c'est le discours que tu sers au dirigeant de ta boite, c'est la bonne méthode. Tu sera malhonnête, mais fortement présenti pour avoir une promotion.

    • [^] # Re: Une technologie révolutionnaire !

      Posté par  . Évalué à 1.

      Pour conclure, je dirais qu'AJAX est au web ce que le nucléaire est à l'énergie : une révolution technologique. Je table que d'ici 10 ans, 90 % du web sera passé à AJAX.

      Vu l'avenir que je prédis pour le nucléaire, je ne donne pas cher d'AJAX. Enfin, ça sert toujours pour le lavage de cerveau...

    • [^] # Re: Une technologie révolutionnaire !

      Posté par  . Évalué à 4.

      « Pour conclure, je dirais qu'AJAX est au web ce que le nucléaire est à l'énergie : une révolution technologique. Je table que d'ici 10 ans, 90 % du web sera passé à AJAX. »

      Bientôt un Tchernobyl du web ? C'est pas sympa pour AJAX de comparer... :)

      Vivement les scripts renouvelables...

    • [^] # Re: Une technologie révolutionnaire !

      Posté par  . Évalué à 3.

      "collaborateurs" : l'euphémisme moderne pour l'éternelle division du travail en chef > sous-chefs > sous-fifres > employés > [CNE?] > stagiaires

      " locations distantes et variables" : à ma connaissance, "location" est un nom féminin signifiant le fait de louer un objet, un bâtiment, et par extension ledit bâtiment. J'adore ce genre d'anglicismes du monde du marketing... euh, je veux dire de la mercatique. Rassurez-moi : le mot "lieu", le mot "endroit" n'ont pas disparu de notre langue, n'est-ce pas ?

      "web-services dans notre applicatif métier" : ... en fait je sèche, là. N'existe-t-il pas dans le vocabulaire français déjà existant des expressions permettant de dire la même chose de manière claire ?

      Je passe sur les sigles délicieusement cryptiques, car n'étant pas un professionnel de l'informatique d'entreprise, je me dis que cela doit "parler" à d'autres lecteurs (j'ai quelques doutes cependant).

      • [^] # Re: Une technologie révolutionnaire !

        Posté par  . Évalué à 2.

        "web-services dans notre applicatif métier" : ... en fait je sèche, là. N'existe-t-il pas dans le vocabulaire français déjà existant des expressions permettant de dire la même chose de manière claire ?
        Les logiciels utilisés sont basé sur un serveur/client http :-D
        Bon ok ca en jette moins style decaideur-pressé qui est tres fort en info.

        toujours est il que le post était justement (amha) une parodie des offres d'emploi/ cursus professionnel décris par un commercial (avec tout pleins de sigles toussa) :)

    • [^] # Re: Une technologie révolutionnaire !

      Posté par  (site web personnel) . Évalué à 4.

      Evidemment, c'est une blaque, le coups des 5000 utilisateurs est classique pour faire un post sérieux (normalement c'est administrateur de 5000 postes sous SUSE en entreprise sous slashdot :-)

      C'est bien rédigé, car c'est bien dans la veine des témoignages des utilisateurs dans les magazines informatiques pour "décideurs".
      Pleins de termes marketing, et finallement, pas de raisons concrétes de l'utilité ou l'inutilité du produit.

      In fine, ça coute soit disant moins cher, mais j'ai rarement vu un produit annonçant que ça va couter plus cher à l'entreprise. :-)

      Petit Lexique pour ceux qui ont la chance de ne pas avoir un abonnement à "Décision Micro/01 informatique" au boulot :-) :

      CRM = Customer Relationship Management, en français, ce sont l'ensemble des méthodes pour traiter la demande des clients d'une entreprise (commandes, demandes d'informations, plaintes, etc...)
      EAI = Enterprise Application Intégration, ça permet de relier les différentes briques d'un système d'information
      TCO = Total Cost of Ownership (le coût total d'un systéme informatique, matériel+licences+maintenance+salaires)
      TMA = Tierce Maintenance Applicative. Dans cet exemple, il dit que grâce à la panacée AJAX ils ont moins de bugs à corriger ou d'évolution à faire.

      Ils ont oubliés d'ajouter qu'AJAX faisait aussi le café !

    • [^] # Re: Une technologie révolutionnaire !

      Posté par  . Évalué à 2.

      joli business loto ! :)

      rigolez pas je connais des gens qui recoivent beaucoup d'argent pour parler comme ca ... mais chut ! faut pas le dire ! :)

  • # Testé et approuvé...en tant qu'utilisateur

    Posté par  . Évalué à 1.

    Mes sites favoris avec des bouts d'ajax dedans :
    http://del.icio.us/
    http://maps.google.com/
    http://www.netvibes.com/
    http://mail.google.com/
    http://google.com/notebook/

  • # Ajax : vas te faire voir chez les Grecs!

    Posté par  (site web personnel) . Évalué à 5.

    [x] je préfère lire dans l'Iliade les exploits d'Ajax, fils de Télamon et roi de Salamine, et du petit Ajax, roi de Locride.

  • # Standard...

    Posté par  (Mastodon) . Évalué à 10.

    On nous rabâche sans arrêt que Ajax, ça utilise des standard... Je dis non ! Ajax est entièrement basé sur l'appel XMLHttpRequest qui est loin d'être un standard [1]. De plus, les sites utilisant Ajax casse le principe de base du web : l'hyperlien. En effet, quand on clique sur une interface Ajax, la page n'est pas rechargée, seule une partie est importée et remplacée. Hors, ce qui fait la nature même du web et dont se servent entre autre les moteurs de recherche, c'est bien d'arriver sur une nouvelle page chaque fois qu'on clique sur un lien.

    Alors arrêtons de dire qu'Ajax respecte les standard, ce n'est pas vrai. Et en plus, c'est moche... Bon, je retourne dans ma salle de bain.

    [1] http://openweb.eu.org/articles/objet_xmlhttprequest/

    • [^] # Re: Standard...

      Posté par  . Évalué à 6.

      Je suis d'accord pour dire que ajax ne respecte pas les standards
      Perso je suis en train de développer une appli en PHP/HTML/CSS/JS
      et on essaye d'utiliser AJAX à son maximum.

      Mais nos besoins justifient ces moyens, ce site ne verra jamais passer un seul moteur de recherche (accès interdit sans un compte)
      Et le besoin en ergonomie est très important.

      Ce qui m'enrage avec les standards : les css
      la norme a en permanence un comportement différents en fonction des navigateurs et si l'on essaie de développer une appli web lourde et complexe, de taille relative, valide CSS2, y'a intérêt à se lever de bonne heure !

      Donc dire que AJAX est un standard : NON
      Mais j'ai des fois presque envie de dire que CSS n'en est pas un non plus (allez-y, fouttez moi :p)

      Mais faut aussi se calmer avec les sacro-saints standards parce que des fois j'ai l'impression que ca fait un peu poudre aux yeux.

      Bien sur, dans le fond je soutiens les standards mais aujourd'hui je suis enervé !

      • [^] # Re: Standard...

        Posté par  . Évalué à 10.

        En même temps, les standards (X)HTML/CSS ont été à l'origine conçus pour afficher des documents "textuels", pas pour faire des vraies applications. Pour preuves :
        * la structure logique d'une page HTML est une structure logique de documents (en-tête, corps de texte, titres, paragraphes).
        * les possibilités de définir des layouts pour positionner les éléments sur une page sont limitées. A part les tableaux (le moins chiant, et le moins propre) et les div flottants (plus propres, mais casse-couilles), c'est la misère.
        * il manque pas mal d'éléments qui composent une interface graphique (Toolbar, Menu, Barre de progression, ...). A part des éléments de formulaire (qui fait plus penser à un hack qu'autre chose), ...
        * dans HTML et HTTP, il y a "Hyper-text", ce qui explicite bien ce que leurs inventeurs voulaient en faire.
        * l'apparition des applets Java, de Flash, de XUL et autres joyeusetés montre bien qu'il y a un manque à combler.

        Taper sur les standards (X)HTML/CSS pour ça, c'est comme dire que LaTeX c'est nul parce qu'on ne peut pas programmer de jeux-vidéos avec.

        • [^] # Re: Standard...

          Posté par  . Évalué à 1.

          C'est pour ça qu'un jour peut-être, XUL ou XAML ou d'autres noms tordus avec des X enverront cette vraie-fausse technologie qu'est AJAX aux oubliettes...

          Oooh, mais j'apprends qu'il existe une fusion AJAX / XUL... ici : http://zk1.sourceforge.net/
          Démo ici : http://www.potix.com/zkdemo/userguide/

        • [^] # Re: Standard...

          Posté par  (site web personnel) . Évalué à 8.

          >En même temps, les standards (X)HTML/CSS ont été à l'origine
          >conçus pour afficher des documents "textuels", pas pour faire des
          >vraies applications.

          Oui et http n'était pas prévu pour faire des applications.
          C'est bien pour ça que le développement Web ne ressemble qu'à un gros bricolage.

          • [^] # Re: Standard...

            Posté par  . Évalué à 1.

            Il disait juste que pour un standard, le fait qu'il se comporte differement est dedomageable... (apres la faute au standard ou navigateur...)

            Peut etre que le HTTP n'est pas un language pour les applications toussa... Mais le fait est que les besoins ont evoule. Les applications qui marchent partout, sur tous les clients, quelques soit le lieux et le materiels... c'est rare...

            Du coup on profite des astuces que cela permet. Ca risque d'evoluer dans ce sens... Pas le temps d'attendre qu'une nouvelle technologie plus axe application se developpe partout... le besoin est maintenant.

      • [^] # Re: Standard...

        Posté par  . Évalué à 2.

        ce ne sont pas les standards qui posent problèmes, c'est le respect de leur implémentation.

        la norme a en permanence un comportement différents en fonction des navigateurs et si l'on essaie de développer une appli web lourde et complexe, de taille relative, valide CSS2, y'a intérêt à se lever de bonne heure !

        hum ! j'espère que tu ne penses pas ce que tu as écris ... car sinon ca veut dire que tu n'as pas tout compris ! :-)

        Je reformule :

        "ce qui m'énerve, c'est que le développement d'une appli web lourde et complexe, de taille relative (NDRL: relative à quoi on sait pas ! :) ), qui utilise du CSS 2 valide àades comportements différents en fonction du navigateur"

        j'ai pas tout mis, mais je pense que c'est ce que tu voulais dire ...

        Donc oui, les implémentations sont pourries, pas les standards.

        • [^] # Re: Standard...

          Posté par  . Évalué à 3.

          Il y a tout de même pas mal de choses qui sont explicitement "implementation-dependant" alors que ça arrange le moins le développeur web.

          Un certain nombre de propriétés CSS qui "ne devraient pas être applicables en (X)HTML" (et autres) telles que display: table, display: table-cell... Mais dont la liste est pas facile à retrouver et du coup chacun y va de son interprétation...

          Le javascript : pas trop difficile de trouver la doc du standard, qui indique la structure du langage, ses mots-clés, etc. Pas trop dur non plus de trouver les docs des DOM 1, 2 et 3 base et HTML. Par contre, pour savoir comment diable on met des points d'entrée dans un document, c'est autre chose. Les initialisations, on les mets où ? Sinon, ça fait quoi si on met un onclick sur un objet qui contient un <a> et qu'on clique dessus ? Ca fait quoi si...
          On sait peut-être tout ça, mais ce n'est écrit nulle part. Le javascript est peut-être standardisé, pas l'API avec laquelle on peut s'en servir pour du web.

          Donc non, le problème ne vient pas que des implémentations incompatibles, buggées ou en retard. Pour être compatible, faudrait déjà savoir avec quoi.

    • [^] # Re: Standard...

      Posté par  . Évalué à -1.

      Sauf erreur de ma part, AJAX sert de base à Web 2.0 alors dire qu'AJAX n'est pas standard n'est pas totalement faux, mais AJAX est bel et bien l'avenir du Web, n'en déplaise à quelques railleur qui crachent sur tout ce qui est nouveau et qu'ils ne comprennent pas.

      • [^] # Re: Standard...

        Posté par  (site web personnel) . Évalué à 3.

        Je préponds ici mais j'aurais très bien pu répondre ailleurs.

        Qu'est-ce que le web ? ce sont juste des documents structurés avec des liens entre ... c'est comme ça a l'origine, presque pas d'images même.

        Maintenant, regardez ce que c'est devenu, des tonnes de truc clignottants, un style différent pour chaque site ... perso, je n'ai pas bien connu le web d'avant mais je le regrette quand même.

        Il y a sans doute un besoin pour les web-applications ... mais a mon avis, il ne faut pas aller taper du copter HTTP/(X)HTML. Je pense qu'il faudrait envisager un protocole qui permette de répondre a ces besoins facilement.
        Même HTTP n'est pas prévu pour les web-applications. Une application nécessite une interface mise à jour en temps réel. HTTP est prévu pour déliverer une page statique, rien à voir.

        En attendant une meilleure solution, personne n'interdit (et personne n'interdira) d'utiliser HTTP/xHTML/CSS/AJAX mais a mon avis, cela devrait être réservé a des cas spécifiques. Les pages qui présentent juste de l'information n'ont rien a gagner d'être associées avec AJAX.

        • [^] # Re: Standard...

          Posté par  . Évalué à 1.

          perso, je n'ai pas bien connu le web d'avant mais je le regrette quand même.

          euh, ca fait vieux con, mais je l'ai connu ... je regrette pas du tout ... même si comme toi, je hais la partie qui clignotte dans tous les sens ...

          mais où commercial vient, rien ne va plus !

          ce sera le dicton du jour !

          a méditer !

  • # Non pittié, pas le foot !

    Posté par  . Évalué à 10.

    [x] je lave ma salle de bain avec

    et surtout pas "vive le foot !", ce mois de compétition sportive qui démarre me rend anxieux, déjà les newsletters des différentes enseignes telles que rdc ou cdiscount affluent avec leurs lots de débilités profondes : a qui achetera le plus grand ecran plasma afin de finalement voir la tête de zidane déçu parce qu'éliminés dès les premiers matchs. Que la france perde et vite, qu'on ne parle plus et qu'on oublie rapidement ce moment désagréable qu'est la coupe du monde !

    çapuelefoot

    Gorfou

    • [^] # Re: Non pittié, pas le foot !

      Posté par  . Évalué à -3.

      C'est clair qu'après avoir vu Allemagne - Costa Rica, je me suis demandé si je regarderais à nouveau un match un jour...

    • [^] # Re: Non pittié, pas le foot !

      Posté par  (site web personnel) . Évalué à 9.

      Donnez au peuple du pain et des jeux, et ils vous casseront moins les couilles....

      • [^] # Re: Non pittié, pas le foot !

        Posté par  . Évalué à 1.

        en même temps c'est éprouvé comme méthode ... et puis après tout que demande-t-on de plus que du pain et des jeux ?

        moi si je pouvais avoir les 2 sans bosser, je pense que je signerai tout de suite ...


        ah, on me souffle dans mon oreille droite que je suis en retard pour la livraison d'une appli ...

        damned !

  • # Ajax oui mais....

    Posté par  (site web personnel) . Évalué à 2.

    En tant qu'utilisateur l'Ajax c'est cool, et pas que pour laver mes chiottes... c'est pour moi un véritable plaisir d'utiliser gmail par exemple.
    En tant que programmeur je trouve que c'est plus un effet de mode qu'une révélation, l'Ajax c'est du javascript bien exploité, c'est pas nouveau
    Pour finir, le principal défaut d'Ajax c'est beaucoup d'utilisateurs désactive souvant le javascript, le javascript c'est bien mais à outrance sa tue !!! (popup, effet visuel partout, ...)

    • [^] # Re: Ajax oui mais....

      Posté par  . Évalué à 3.

      Moi je dis vive Noscript [1] !!! Et mort à l'Ajax, d'Amsterdam ou d'ailleurs :p

      [1] : https://addons.mozilla.org/firefox/722/

    • [^] # Re: Ajax oui mais....

      Posté par  . Évalué à 4.

      C'est vrai, il y a des forcenés, des écoterroristes de la bande passante qui naviguent sans images, sans Javascript, sans flash... et personne ne pense à nous :-).

      C'est inimaginable toute la connaissance utile que l'on peut mettre dans une page de 15 ko bien pensée et tout ce que l'on peut mettre d'inutile dans une page clignotante de 400 ko.

      A David Braben :

      "Daaavid reviens, daaavid reviens, david reviens parmi les tiens."

  • # Un besoin de l'industrie du logiciel ?

    Posté par  (site web personnel) . Évalué à 7.

    L'ajax, n'est qu'une tentative de plus de transformer les clients web en interface riche.
    Ces technologies, dans la même veine que les web services, permettrons surtout aux fabricants de logiciels d'inventer des modes de distribution adaptés au piratage de masse et autres evolutions du comportement des consommateurs.

    _ Logiciels en ligne gratuits, payés par la pub et le vol de données

    _ Clients lourds gratuits auquels on peut ajouter des fontionnalitées par abonnement.

    _ implémentations d'algorithmes brevetés en location
    ...

    Les avantages sont nombreux :
    _ plus de piratage
    _ plus de questions de portabilité
    _ plus d'ingenieurie inversée
    _ substitution partielle de la qualité des algorithmes à la qualité de l'infrastructure réseau.




    Il me semble que :

    _ tout celà n'a plus rien a voir avec le web au sens premier (mise à disposition d'information organisée avec des hyperliens).

    _ La vrai question (ici) est celle de l'évolution des logiciels libre dans ce contexte.

    Note :
    En écrivant ces lignes je réalise à quel point l'interface gmail (que j'utilise) n'est rien de plus qu'un client mail propriétaire. Ça me fait bizzarre. Un peu comme si j'utilisait Outlook Express.

    • [^] # Re: Un besoin de l'industrie du logiciel ?

      Posté par  . Évalué à 3.

      C'est un point interessant que tu souleves : la dérive Googlisante du business model de l'industrie du logiciel. Après IBM (seul le matériel a de la valeur), Microsoft (c'est le logiciel qu'on vend comme un produit), et la vague du libre (la valeur est dans le travail fourni), voici la phase [de tentative] d'appropriation des données. (bien sûr tout ceci n'est pas tranché, on peut mélanger les phases parfois entre elles)

      Pour continuer sur Ajax, et sans vouloir nier les effets négatifs que tu mentionnes, AJAX, c'est aussi un moyen de rendre nos applications libres simplement plus ergonomiques :
      - les webmails comme Squirrelmail et Imp ont beaucoup à y gagner
      - les diverses interfaces de configuration aussi
      ... à condition de l'utiliser à bon escient...


      Pour moi, Ajax peut donc apporter des fonctionnalités interessantes. Et en quelque sorte, Ajax peut réussir à apporter ces fonctionnalités là où Java avait échoué (souvenons nous que Java a été conçu au départ pour tourner en Applets coté client, et était supposé être portable). (fin du [semi] troll).

  • # A mort le flash

    Posté par  (site web personnel) . Évalué à 5.

    Personellement une des chose les plus importantes que j'attend de AJAX et ses evolutions prochaines (ECMA/Javascript 3 toussa), c'est la mort du flash proprio et la libéralisation d'une partie du web.

    Et vive le JS + AJAX libre! (prototype, scriptaculous, rico etc..)

    • [^] # Re: A mort le flash

      Posté par  (site web personnel) . Évalué à 2.

      Effectivement, si une extension du javascript, accompagnée d'une standardisation un peu plus forte pouvait voir le jour et s'imposer, on pourrait enfin se débarrasser du flash qui :
      - allourdit les pages
      - fatigue les yeux
      - prive l'utilisateur de sa liberté. Par exemple, pas possible d'enregistrer une vidéo - bien que téléchargée en locale - depuis GoogleVideo, car c'est du flash : un logiciel fermé installé sur notre propre PC !

  • # La lettre importante dans "AJAX"

    Posté par  (site web personnel) . Évalué à 6.

    Salut,

    AMHA, la lettre importante dans AJAX, c'est le premier A.
    Le coté asynchrone est la seule chose qu'on pourrait qualifier de plus ou moins "nouvelle" (je n'ai pas dit révolutionnaire, faut quand même pas exagérer).

    Bref, ce côté asynchrone que les puristes du HTML réprouvent permet quand même d'améliorer sensiblement les sites web.
    Et si c'est conçu comme il faut, ça ne casse pas la navigation existante et classique, ça améliore juste pour ceux qui ont le javascript activé.

    Prenons un exemple :
    L'inscription à un site, où il faut remplir un formulaire en choisissant notamment un login (oui, comme ici sur linuxfr). Avec la méthode tradi, l'utilisateur remplie le formulaire, qui est envoyé au serveur, qui vérifie les valeurs saisies. Si le login est déjà utilisé, alors la page qui se recharge indique "essayez autre chose" ou un truc du genre.
    Vous connaissez tous ça. Ce qui est faisable avec Ajax (ou plutôt une requète asynchrone faite en javascript), c'est de vérifier au fur et à mesure de la frappe du login par l'utilisateur si ce login est dispo ou pas. Et s'il n'est pas dispo, d'afficher par exemple un "KO" rouge à côté du champ de saisie, puis un "OK" vert si le login est dispo lorsqu'il est modifié.
    L'utilisateur qui a le js activé aura une validation quasi immédiate du login, alors que celui qui ne l'a pas devra envoyer le formulaire pour savoir si le login est dispo ou pas.

    Vous voyez, AJAX n'est pas une infamie : s'il est utilisé correctement c'est un plus pour le visiteur du site.
    Par contre pour le développeur, ça demande plus de boulot. Il faut en faire autant qu'avant, PLUS la partie de traitement des requètes asynchrones (en js côté client + en PHP/Python/Ruby/etc côté serveur).

    Alors ? Convaincus ? :-)

    Yann

    • [^] # Re: La lettre importante dans "AJAX"

      Posté par  . Évalué à 3.

      Question sécurité c'est pas jojo, cet exemple. La vérification d'existence d'un nom d'utilisateur (auquel est donc associé un compte, ou pas) doit être laborieuse pour les utilisateurs dont on ne sait pas grand-chose.

      • [^] # Re: La lettre importante dans "AJAX"

        Posté par  . Évalué à 1.

        C'était juste un exemple.
        Un exemple est de penser à 2 listes : on choisit un élément de la 1re liste et automatiquement, les éléments correspondant sur la 2e apparaissent.
        Un autre : une compétion automatique dans un champs input : si pas de js, pas de complétion.

      • [^] # Re: La lettre importante dans "AJAX"

        Posté par  (site web personnel) . Évalué à 1.

        Ce n'est ni plus ni moins sécurisé que sans ajax.
        La sécurité doit être ailleurs, AMHA, mais là ça devient hors sujet (ce n'est plus spécifique à ajax, mais général aux "applis web").

    • [^] # Re: La lettre importante dans "AJAX"

      Posté par  (site web personnel) . Évalué à 3.

      sauf qu'a mon avis, les formulaires n'ont pas trop leur place dans les pages html (même si je les utilise faute de mieux sur mon site).
      Pour l'authentification, le truc qui marche bien c'est l'authentification HTTP ... le navigateur te sort une boîte de dialogue pareille pour tous les sites, tu la reconnais facilement et il peux même mémoriser facilement ton login et ton mot de passe.

  • # Ajax: ça serait pas ...

    Posté par  . Évalué à 3.

    un nouveau produit pour dégraisser les portes-monaies?

  • # Ajax, gros buzz, mais pratique...

    Posté par  . Évalué à 3.

    Marrant, en lisant ce sondage, je me suis posé la question "mais c'est quoi ajax"... quelques docs plus loin, j'étais en mesure d'ajaxifier une de mes applications PHP développée au boulot...

    Bon, ben Ajax, c'est pas du vaudou, c'est pas de la magie noire, c'est en fait simple, pour ne pas dire tout con, c'est très pratique quand on a des pages composées de zones générées dynamiquement depuis une db (en l'occurence, il s'agit ici d'un inventaire de suivi d'un parc de serveurs, avec des fiches de config hardware et software assez détaillées).

    Pour des applications web, c'est tout de même une technique pour avoir un chargement plus intelligent des pages contenant des zones de contenus générés dynamiquement. Un bon remplacement des frames.

  • # Mon avis...

    Posté par  . Évalué à 3.

    c'est que AJAX c'est un peut le ms office du web. c'est a dire on met tout dans la presentation et on dit que c'est révolutionaire. Moi j'inventerai bien le web -1 ou tout resemblerai a du docbook, c'est a dire que sur le web y'aurai que des données et pas de présentation du tout.

    genre:
    <gallery>
    <image>
    <thumbnail src="truc">
    <data src="machein">
    </image>
    <image>...

    ou

    <mail>
    <from>gnia@truc.com</from>
    <body>blabla...

    en fait ça existe deja bien sur, les flux rss par exemple sont tres bien je trouve, si seulement tout pouvait etre comme ça.

    • [^] # Re: Mon avis...

      Posté par  . Évalué à 2.

      ce que tu décris, à savoir ton exemple de séparation données/présentation, c'est du xml...

      et ajax est justement fait pour manipuler du xml. Avec un navigateur supportant le xsl/xslt, il est totalement possible de garder cette séparation tout en faisant une interface dynamique basée sur des principes ajax.

      Ajax est moins une question de présentation qu'une question de manipulation des données, celà permet de charger un modèle de données au fur et à mesure des besoins de l'utilisateur plutôt que de lui envoyer un dump complet en une fois avec des choses dont il n'aura pas forcément besoin. Avec un système ajax, on peut donc charger les informations de base d'un modèle et puis importer morceau par morceau des données supplémentaires en fonction des besoins.

      Ajax, c'est juste une technique, le résultat dépend entièrement de ce que les développeurs en font.

      • [^] # Re: Mon avis...

        Posté par  . Évalué à 1.

        je sais pas si vous savez mais vous n'êtes même pas obligés d'utiliser xslt ...

        un doc xml et une css2 et zou l'interface est la même ...

        faut juste que le navigateur supporte xml ...

        et plus de html à générer et de temps cpu à perdre à faire de la transformation couteuse ...

        mais bon je m'égare de "l'ajax WC qui néttoie tout du sol au plafond"

  • # Moi j'aime Ajax

    Posté par  . Évalué à 3.

    En faite j'aime surtout Ajaxterm, de l'Ajax + python. Et j'aime mon Gmail.

    Après le full Ajax je suis pas sur de son interet. J'aime bien les site informatif, simple lisible depuis mon elinks (navigateur mode texte pour ceux qqui connaissent pas). Très pratique pour travailler et aller à la chasse aux info, lorsqu'on a pas d'interphace graphique.

    Donc Ajax oui, mais pas à toutes les sauces. C'est comme tout, en abuser ça craint.

    • [^] # Re: Moi j'aime Ajax

      Posté par  . Évalué à 2.

      si le navigateur supporte le javascript et le xmlhttpRequest, ça marche, maintenant, effectivement, si ces deux éléments ne sont pas présents, il y a problème.

      Ajax à toutes les sauces n'est certainement pas une bonne idée, mais pour des applications intranet, ça a une bonne valeur ajoutée.

      Maintenant, c'est aux développeurs de mettre aussi en place des mécanismes permettant d'afficher les infos sans passer par ajax pour les navigateurs ne supportant pas le xmlhttprequest, donc la majorité des navigateurs texte et pour malvoyants.

    • [^] # Re: Moi j'aime Ajax

      Posté par  . Évalué à -1.

      si le navigateur supporte le javascript et le xmlhttpRequest, ça marche, maintenant, effectivement, si ces deux éléments ne sont pas présents, il y a problème.

      Ajax à toutes les sauces n'est certainement pas une bonne idée, mais pour des applications intranet, ça a une bonne valeur ajoutée.

      Maintenant, c'est aux développeurs de mettre aussi en place des mécanismes permettant d'afficher les infos sans passer par ajax pour les navigateurs ne supportant pas le xmlhttprequest, donc la majorité des navigateurs texte et pour malvoyants.

  • # Page francophone de Wikipedia sur AJAX

    Posté par  . Évalué à 1.

    Juste pour signaler que la page francophone de Wikipedia est disponible : http://fr.wikipedia.org/wiki/AJAX (voir sondage)

    Merci

  • # A utiliser avec parcimonie

    Posté par  (site web personnel) . Évalué à 2.

    A l'époque ou j'ai fais du web 2.0 quand le terme n'existait pas encore, on avait fait une application dynamique par zone en s'appuyant sur du javscript+appels serveurs.

    Et bien à maintenir ou faire évoluer, c'est un peu le foutoir.

    On a quand 2 langages (java, javascript) et 2 syntaxes de descriptions (html, css), des points d'entrés asynchrones qui sont appelés après tout un cheminement de navigation, et une navigation qui dépend du client et du serveur.

    En plus le javascript étant tellement standard entre les familles de navigateurs :-) on a un peu du code spaghetti côté client.

    Depuis, je suis trés circonspect sur l'utilisation du javascript côté client et je l'utilise pour le strict minimum.

    Et puis Ajax s'est imposé malgrès son côté bidouille, car il s'appuit sur des composants standards, alors qu'il faut ajouter un pluggin flash ou java pour faire un client lourd en web.

    <délirium tremens>
    Si les constructueurs et les éditeurs se mettaient d'accord sur un protocole asynchrone qui permette de faire des applications client/serveur avec la gestion de l'affichage côté client et le traitement des données côté serveur, on aurait pas besoin de bidouiller en javascript.
    Mais pour cela, il faudrait bien évidemment se mettre d'accord sans essayer de pousser une techno propriétaire qu'on veut faire payer à tout le monde !
    </délirium tremens>

  • # testé et desapprouvé

    Posté par  . Évalué à 7.

    testé et désapprouvé : mais uniquement sous sa forme actuelle, l'avenir reservera peut-être des surprises (mais j'en doute...).

    Attention: la suite de mon commentaire ne couvre que l'utilisation que j'ai faite d'"ajax". Je suis bien concient qu'il y a des cas de figure assez courants (mais tout de même particuliers) pour lesquels un petit coup d'ajax bien placé apporte réellement un gros plus.

    Au chapitre des griefs : l'objet xmlhttprequest est : difficile à créer (bien que le même petit bout de code ce copie colle un peu partout et voyage sur la toile :). Difficile à utiliser : divers bugs d'IE et de Moz rendent la programmation extremement fastidieuse. Remarquez c'est la même came que le javascript en général question compatibilité entre navigateurs.
    Mais ce n'est pas tout : une fois xmlhttprequest maitrisé (une bonne journée mini pour découvrir pas mal de problème et autant de moyen différents de les contourner) (et on se rend bien souvent compte dans un deuxième temps que ce n'est parce qu'il marche souvent pas trop mal qu'il est utilisé correctement au sein d'un code et ne posera jamais de problème), il reste encore à faire un bon gros^W énorme coup de DHTML pour faire de la modif dynamique sur un langage de description qui n'a jamais été conçu pour ça. Ce qui en résulte est d'une extrème lourdeur et d'un très grande complexité. D'autant plus qu'avec une conception récente l'html complet d'une page est souvent assez petit et que dans bien des cas (mais pas tous ! certes) un rechargement complet serait très efficace et simplifirait beaucoup la conception.
    Enfin ajax a tendance à éclater les différents aspect d'un logiciel web-based et à multiplier le nombre de composants et donc d'interfaces necessaire à sa réalisation.

    Alors bien sûr on couvre quand même un énorme besoin. Mais à quel prix ? Pour se faciliter la tache on peut rajouter un framework pour abstraire tout ça et éviter les petits désagrement (enfin le "on peut" est assez relatif parce que bien souvent, "on peut" pas :). Mais jusqu'à quand continura-t-on à empiler les couches ? Enfin tous les besoins ne sont pas couvert (exemple: push d'un evenement en provenance du serveur impossible, necessité de faire faire un polling par le client, beurk :/)

    Ma conclusion et qu'il reste à inventer un concurrent à l'html et toutes les techno sous-produit de l'html qui gravitent autour pour concevoir des interfaces type client leger vraiment dynamiques et efficaces, déployables partout dans le monde avec une grande efficacité, un design simple, etc, etc... Malhereusement pour les raisons de backward compatibility et autre habituel, je ne vois ça arriver ni à cours ni à moyen terme. Snif :/

    • [^] # Re: testé et desapprouvé

      Posté par  . Évalué à 3.

      bon alors on va me taper sur la tête mais c'est pas grave ...

      on peut utiliser tout ca depuis longtemps ...

      EN 1995 netscape utilisait Liveconnect ... techno rigolote qui permettait d'interfacer java et javascript (accès aux méthode java depuis javascript et lycée de versailles)

      - inconvénients par rapport à ajax : une applet java à charger (mais sans interface quand même, juste en fond donc quelques ko tout au plus ... on lance la jvm je suis d'accord).

      - avantages par rapport à ajax : une sécurité meilleure !

      car on exécute l'applet dans la sandbox, on n'accède qu'au serveur qui l'a lancé et le client peut la refuser .... tout ce qu'il ne voit pas avec ajax ...

      sinon ca permet au serveur de pouvoir pusher ...

      bref c'est bien rigolo et ca marche sous Netscape, moz, ie, opera, firefox, i tutti quanti qui supporte java ... depuis 10 ans ...

      web 2.0 une révolution vous avez dit ....

      y avait un business loto en route non je crois ?
      :-)

      • [^] # Re: testé et desapprouvé

        Posté par  . Évalué à 1.

        Ouais, enfin, c'est pas un scoop qu'AJAX est une technologie particulièrement daubesque pour faire ce qu'elle fait (normal vu que ce n'est pas une technologie, en fait).

        En conséquence, j'en déduis que sa popularité vient surtout de son potentiel à marcher partout, tout de suite, avec pour seule contrainte que l'utilisateur ait un navigateur web (javascript étant activé par défaut, et désactivé par des gens qui le savent très bien et ont l'habitude que rien ne marche en dehors de leurs sites préférés).
        La contrainte "plus une JVM connue de ce navigateur" est devenue une vraie contrainte supplémentaire, surtout avec ce §%*£$ de flash.

        Deuxième avantage, AJAX fait du full opensource sur ce qui est exécuté lecôté client, et obtient ainsi un taux de méfiance inférieur à ce qu'obtient une javapplet obscure, du moins vis-à-vis des geek (c'est fou comme je paie mes impôts avec simplicité et confiance).

        Conclusion : ton machin Liveconnect ça fait pas ce que fait AJAX, point. Au mieux ça le faisait déjà à l'époque où c'était pas concevable d'avoir un navigateur sans JVM, mais à cette époque les possibilités du web n'étaient pas franchement les mêmes.

        • [^] # Re: testé et desapprouvé

          Posté par  . Évalué à 0.

          La contrainte "plus une JVM connue de ce navigateur" est devenue une vraie contrainte supplémentaire, surtout avec ce §%*£$ de flash.

          oui ca je suis d'accord ... maintenant les potentiels apportés par java et flash sont quand même "légèrement" différents ...

          côté sécurité, ton applet java est beaucoup plus sécurisée car au moins elle n'échange des infos qu'avec le serveur d'où elle vient quand elle n'est pas signée ... tu sais avec qui tu causes ...

          avec ajax tu peux aller chercher des infos partout ... mais aussi en envoyer ...

          bref une arme absolue de phishing ... sans que quiconque s'en appercoive ... d'ailleurs ca m'étonnerait pas que ca arrive rapido ca ...

          sinon pour la conclusion :

          Ajax permet d'envoyer des informations assynchrones entre un serveur et un client sous format XML. tu es d'accord la dessus je pense.

          Liveconnect fait la même chose avec java en 3 méthodes avec le petit avantage que tu peux réaliser des traitements de retour et préparer tes infos avec un langage "un peu" mieux que cette daube de Javascript ...

          Liveconnect n'est pas la solution miracle, mais elle existe depuis 10 ans ... côté maintenance c'est assez sympa comme truc ... attention je le défend pas hein ... je dis juste qu'ajax n'est pas la révolution qu'on anonce dans les salons (je ne parle pas de tous les problèmes d'indexation, etc ...)

          Enfin de toute façon, on peut pas lutter AJAX est une mode et on ne lutte pas contre une mode ...

          par exemple python ... le langage geek par excellence ... un truc qui est tabluation dépendant ... je crois rêver !!!

          • [^] # Re: testé et desapprouvé

            Posté par  . Évalué à 0.

            Soit, on vire le côté sécurisé, en fait c'était n'importe nawak. (Pu***** j'avais même pas remarqué ça)

            Seul avantage donc, zéro dépendance, et c'est l'avantage qui en a fait une mode. Comme je ne reconnais rien de techniquement bon en AJAX, j'en conclus donc que pour "faire la même chose qu'AJAX", il n'y a aucun besoin de faire propre, robuste, sécurisé ou autre. Par contre il est indispensable d'avoir zéro dépendance et d'avoir un bon temps de réponse (genre ne pas recharger systématiquement toute la page).

            par exemple python ... le langage geek par excellence ... un truc qui est tabluation dépendant ... je crois rêver !!!

            (Mauvais exemple pour moi, je connais pas encore python. Je compte m'y mettre, et effectivement les tabulations ça m'enchante pas, mais là la mode alimente la mode : les langages source libres avec un tel bagage de bibliothèques, ça court pas les rues. Faut que j'essaie aussi ruby.)

          • [^] # Re: testé et desapprouvé

            Posté par  . Évalué à 4.

            avec ajax tu peux aller chercher des infos partout ... mais aussi en envoyer ...


            Non, des navigateurs comme firefox refusent qu'un javascript utilise xmlhttprequest pour pomper ou envoyer des données venant d'un autre site que celui dont le script est originaire (je suppose que pour I.E. c'est pareil)

            bref une arme absolue de phishing ... sans que quiconque s'en appercoive ... d'ailleurs ca m'étonnerait pas que ca arrive rapido ca ...


            Déjà utilisé pour le phishing depuis belle lurette, des mesures ont été déjà prises (comme la restriction sur le site)

            Si tu crains pour le phishing, n'hésite pas à utiliser le https (qui est le minimum syndical pour le développement d'applications où la vie privée des utilisateurs est en jeu)... et n'hésite pas non-plus à implémenter des sécurités server-side (parceque croire un client sur parole, dans un contexte client-serveur avec des données sensibles, c'est du suicide)

            Le phishing est une réalité qui dépasse de loin un gadget comme xmlhttprequest, si tu te prémunis correctement contre le phishing, tu n'as pas grand-chose à craindre de xmlhttprequest, si tu bâcles, effectivement, ça pourrait agrâver un peu la situation.

            • [^] # Re: testé et desapprouvé

              Posté par  . Évalué à 3.

              je suppose que pour I.E. c'est pareil


              Rectification... il semble que IE dans sa grande générosité permet effectivement de pomper des données depuis d'autres sites que celui dont le script est originaire... (testé avec succès sur la machine du boulot, qui n'est pas très à jour question patches)

              Bravo Microsoft!

  • # Le futur

    Posté par  . Évalué à 2.

    En fait, dans AJAX le concept est bon; c'est juste que les outils ont au départ pas été conçu pour. Genre le HTML, fait pour les documents statiques.
    Mais les initiatives se multiplient, comme ZUL, ZAML en attendant un standard du W3C, et surtout JavaScript2, avec un gros travail de fait pour les performances (typage statique, classes, ...) et qui sera donc en théorie aussi rapide que Java ou .NET !
    L'avenir nous réserve sûrement de grosses surprises, et je ne pense pas que la poussée du libre n'y soit pour rien...
    Wait and see.. cela nous réserve que du bon donc, à condition que les standards soient respectés :)

    • [^] # Re: Le futur

      Posté par  . Évalué à 1.

      >>et qui sera donc en théorie aussi rapide que Java >>

      Aïe, donc le futur est en marche arrière (au passage un hommage à Pierre Christin). Après l'Ajax facile sans frotter et réutilisable (très business loto la "réutilisabilité"), le Java rapide, moui moui moui...

      Sinon Ies queIques trucs que j'ai vu en XUL (CELTIX) étaient bien : interface sobre et claire, bonne utilisation des onglets. Me pencher plus sérieusement dessus je dois.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.