maximettb

Eclipse + Aptana + PHPEclipse Le trio gagnant !

Je crois qu'il y'a une erreur dans le fichier XML généré : il y'a plusieurs balises "root" : <?xml version="1.0" encoding="utf-8"?> <titre>Le titre</titre> <lien>http://lelien.netcom/</lien> <description>La description</description> <image>http://lelien.netcom/image.png</image> Un XML n'accepte qu'un seul noeud root. Il faudrait donc plutôt quelque chose du genre : <?xml version="1.0" encoding="utf-8"?> <site> <titre>Le titre</titre> <lien>http://lelien.netcom/</lien> <description>La description</description> <image>http://lelien.netcom/image.png</image> </site> Ou alors, je n'ai rien compris à ton problème ;-)

À vérifier, mais il faut bien faire la différence entre entités HTML (é , &ccirc; , etc. ) et entités XML (il n'y en a que 5 : < , > , & , ' et " ) qui sont 2 choses bien distinctes. Le mieux est encore d'envoyer les caractéres tel quel, dans un CDATA, sans réencodage.

Un autre tuto pas mal : http://openweb.eu.org/articles/objet_xmlhttprequest/

Le top du top, c'est quand même d'avoir plusieurs feuilles de style, pour en plus faciliter la tâche des daltoniens.

Pas de différence de ce point de vue là entre Perl et PHP, les valeurs des champs sont envoyés de la même manière et ça ne change en rien la manière de les récupérer dans ton script. En gros, en Perl, un simple script comme le suivant fonctionne : #!/usr/bin/perl use CGI; my $cgi = new CGI; my $mon_parametre = $cgi->param('monParametre');

Et puisqu'on est dans la partie ergonomie, pourquoi ne pas mettre les descriptions en avant, et non les caractéristiques du livre. Après tout, la description de l'ouvrage est tout de même bien plus important que ses dimensions !

Après renseignement, il semblerait que ce soit l'API utilisée par Google Mail et Google Maps. Donc, point de vue performance, je pense qu'on a déjà vu pire ! Je suis étonné du peu de documentation, d'exemples et d'avis que suscite cette librairie...

Bonjour, Jai découvert récemment lexistence de loutil Google AjaXSLT, qui permet de coder facilement une transformation de retour XML Ajax en XHTML ( ou autre ) à laide dune simple feuille de style XSLT, le tout côté client ( chapeau Google ! ) . Plus quintéressé par ce procédé, jaurais aimé savoir si certains dentre vous lon déjà utilisé et si vous et vos utilisateurs en êtes satisfait. Bien que sur le principe, cet outil ma lair particulièrement intéressant, jai quelques doutes, peut-être infondés, sur la performance de cette librairie pour le client. Merci davance de partager vos expériences !

Bonjour, Je suis en train de développer une petite application Ajax, mais je suis confronté à un problème : Quand je récupère une réponse AJAX du style : <response> <component id=monComposantId> <div id=blabla> Du contenu HTML... </div> </component> </response> Jaimerais pouvoir récupérer le contenu de la balise « component » sous forme de texte HTML brut ( un peu dans le style innerHTML ) , or je ne sais récupérer que les childNodes. Une solution consiste à échapper toutes les ouvertures/fermetures de balises à lintérieur même de la balise component puis récupérer le nodeValue, mais ça ne marrange pas du tout. Quelquun a-t-il un équivalent de innerHTML lors du parsing de réponses Ajax ? Merci davance. Max

À vérifier, mais la version 2 contient quelques caractères en plus, comme par exemple le sigle .

Ce genre de librairie n'existe t-il pas déjà ? Par exemple, l'excellent Google Ajax API ?

Comme ça, je n'ai aucune idée de comment charger le javascript après le chargement total de la page. Par contre, pour la méthode de l'iframe, tu peux peut être utiliser getElementsByTagName pour retrouver tous les liens, puis rajouter un target='top' sur ceux-ci.

Je pense qu'il faut utiliser Ajax avec des pincettes. Le vrai danger est d'utiliser Ajax pour utiliser Ajax. Bien souvent, celà n'a tout simplement aucun intérêt et est utilisé à mauvais escient. Ajax ouvre des perspectives absolument géniales pour les APPLICATIONS en ligne. Les sites internet ont finalement peu d'intérêt à utiliser Ajax, car il empêche certains utilisateurs d'accéder au contenu. Après, c'est sûr, on peut envisager une stratégie de double développement Ajax/Pur HTML de manière à ce que tout le site soit accessible avec Javascript désactivé. Après, est-ce que le coût de tels développements est justifié ? Mon intuition me dit que non. Mon (bien humble) avis est que rien ne vaut un bon site en pur HTML, pour son accessibilité, mais également parce que les intéractions sont connues de tous. Pourquoi un site de e-commerce devrait perdre de l'argent parce que l'utilisation d'Ajax compléxifie son utilisation et lui fait perdre des clients peu expérimentés ? Et même si l'interface Ajax est bien conçue, pourquoi un site de e-commerce devrait perdre de l'argent en développements Ajax futiles qui n'apportent rien de plus au service proposé ?

Je n'utilise pas de facteur de qualité, le défaut est donc à 75. Je vais essayer en augmentant ce critère de qualité, mais je ne sais pas si ce critère de compression pourra améliorer un peu les choses. Merci.