Ajax et DOM - Page 3

clair...

enfin bon, on s'ecarte du sujet d'origine, qui était, suite à la récupération en HTTPrequest d'une page XHTML, la récupération du contenu d'une balise précise, en vue de remplacer le contenu d'une zone spécifique de la page affichée dans le navigateur (si je ne me suis pas tompé)

et d'ailleurs, en ecrivant ainsi le pb, je vois une autre utilité : prendre par exemple la page d'un site externe, pour en prendre une zone et l'afficher sur la page d'un site perso (style les actus du journal le monde, ou autre)

nEUrOO > oué enfin le langage qui décide d'une version à l'autre de changer l'effet du "=" sur les objets (cf un autre topic par ici), c'est quand même un peu dommage pour la comptabilité

Spipu > ouep, mais pas forcément d'une balise précise, juste d'une "partie de la page" (me repérer par l'id d'une balise ça faisait partie de la solution que j'avais voulu tenter au départ). En revanche comme tu dis, avec une technique comme ça y'a moyen de prendre un bout d'une page externe qui n'a pas été prévue pour ça et l'intégrer ailleurs, je n'y avais pas pensé mais ça peut avoir ses avantages ^^

Zephyr (./62) :
nEUrOO > oué enfin le langage qui décide d'une version à l'autre de changer l'effet du "=" sur les objets (cf un autre topic par ici), c'est quand même un peu dommage pour la comptabilité

c'est clair... de meme de retirer les register global ds PHP6 il semble...

Zephyr (./62) :
Spipu > ouep, mais pas forcément d'une balise précise, juste d'une "partie de la page" (me repérer par l'id d'une balise ça faisait partie de la solution que j'avais voulu tenter au départ). En revanche comme tu dis, avec une technique comme ça y'a moyen de prendre un bout d'une page externe qui n'a pas été prévue pour ça et l'intégrer ailleurs, je n'y avais pas pensé mais ça peut avoir ses avantages ^^

si tu ne le repère pas pas un ID, tu veux faire comment ? lui dire que c'est la DIV dans le TD dans le TR dans la TABLE du BODY ?

Zeph: bah c'est pas ce que je dis?

Spipu: prendre une page externe avec un xhr... directement?

nEUrOO (./64) :
prendre une page externe avec un xhr... directement?

la, je fais mon inculte : késako ?

p-e moi qui n'etais pas clair mais je parlais basiquement du XMLHTTPRequest et de la Same Origin Policy

et op, encore un petit tour : "Same Origin Policy", késako ?

Oh bah la tu pourrais le googler hein!
Ca veut dire que tu peux pas recupere sur des serveurs autres que le tiens des fichiers: quand tu fais un XHR, ca ne marche que sur ton serveur (directement), pas de xhr.open("get","http://yahoo.com/news") en gros.

ah vi c vrai, j'avais oublié ce détail. Tout comme tu ne peux pas acceder au contenu d'une iframe si son contenu n'est pas du meme domaine que toi....

mais bon, ca c pas grave...

suffit de faire un fichier get_page.php?url=...... avec
<?php
if (!isset($_GET['url'])) exit;
echo file_get_contents($_GET['url']);
?>

oui, c'est ce qu'on appelle faire un proxy (mais dans ton cas, ca marchera simplement sur des serveurs non securies, file_gets_contents ne devrait chopper que des fichiers locaux -- dans l'APACHE Document Root; utiliser cURL sinon)

vi, je sais, ca dépend du mode de sécurité de fopen, mais c'était pour le principe...

sinon il suffit de se faire un petit snoopy->fetch, comme ca on peut simuler les session/cookies/protection 401/get/post facilement en fonction de ce qu'on veut recuperer...

juste comme ca, pourquoi ne pas faire tout simplement un fichier php qui prend 2 parametres : l'url de la page à charger, et une chaine de charactère permetant d'identifier ce que tu veux ? comme ca en plus tu ne renvoies au navigateur que ce dont il a besoin. C'est sur que ca fait un petit peut de charge côté serveur, mais je ne pense pas enorme, et qui est compensé par le fait que tu n'envoies que le necessaire

[edit] correction de fautes... désolé...

Oui, c'est une autre solution qui me semble pas stupide. Tant qu'à faire et vu que ça risque d'être assez lent pour parser la page en PHP, on peut surement adapter le truc (peut-être modifier un peu la page qui s'occupe de l'affichage et lui ajouter un paramètre lui permettant de "sauter" certaines parties qui ne seront de toutes façons pas utilisées après le découpage); ça ne conserve qu'un inconvénient à mes yeux par rapport à de l'ajax "normal" : on se paye le chargement de la page complète même pour n'en demander qu'une petite partie.

Zephyr (./73) :
on se paye le chargement de la page complète même pour n'en demander qu'une petite partie.

tu veux dire la construction de la page je suppose. bien que chargement, par rapport à téléchargement, ca se tient ^^


mais sinon, de tout facon, tu t'en moquais bien au départ de ce pt, vu que tu voulais prendre une page complete en httprequest pour n'en garder qu'un bout au final, non ?

non non je ne m'en moquais pas, c'était la moins pire des solutions dans ce que j'avais envisagé au début, mais grâce à ce topic je me suis rendu compte qu'il y avait surement bien mieux à condition de se creuser un peu ^^

lol ok

Spipu (./53) :
et je rajouterais que je n'aime pas la premiere utilisation, car n'est "mettre de l'ajax" pour "mettre de l'ajax", ce que fait beaucoup de monde, et qui ne devrait pas être fait...

Ras le bol des sites qui utilisent de l'AJAX (ou pire, des technologies lourdes comme le Flash, les applets Java etc.) pour des fonctionnalités qui peuvent parfaitement être proposées en simple HTML!

tu as activé le javascript K² ?

Oui (mais certains sites en AJAX utilisent du code non-standard IE et/ou Mozilla qui ne fonctionne pas avec Konqueror ), mais pas le Java ou le Flash (que je n'ai même pas installé).

faut dire que konqueror (et safari qui a je crois le meme moteur) sort vraiment du lot

Ce n'est plus tout a fait le même moteur (les sources ont divergé), d'où les flamewars KHTML vs. WebKit qu'il y a actuellement au sein de KDE (depuis que WebKit a une version Qt soutenue par Trolltech).

pour revenir au sujet :

Zeph, si ca t'interesse, je viens de me faire un script qui apparement marche pas trop mal. La syntaxe d'utilisation est assez simple.
Exemple : la ligne suivant me récupère automatiquement sur yaronet la 6em div du premier body, ce qui veut dire la liste des connectés. et ca marche nikel
http://spipu.net/test/get/?url=http://www.yaronet.com/&id=body|1,div|6
si tu veux je poste mon code ici

[edit] j'avais mis une adresse locale, désolé

mci c'est sympa, mais je ne suis pas encore sûr d'utiliser cette solution, et le cas échéant je m'en sortirai je pense

okesh.

pour info, je n'ai pas utilisé les fonctions de parsing intégrés à PHP, mais j'ai recodé moi meme afin de ne mettre que l'essentiel

Spipu (./84) :
pour info, je n'ai pas utilisé les fonctions de parsing intégrés à PHP, mais j'ai recodé moi meme afin de ne mettre que l'essentiel

Et c'est pas dommage? Les builtin functions sont souvent plus rapides je pense... non?

sauf que je n'avais pas besoin d'un parsing complet.... mais juste de lire les ouverture et fin de balises spécifique. du style dans l'exemple de ./82 uniquement les <body </body <div </div

(au fait, ton site des vélib marche plus?)

ah tiens, je n'ai plus les plans qui apparaissent faut que je corrige ca!

[edit] voila, c'est corrigé petit pb de num de version dans les cartes google

En reprenant le train un peu en route (j'espère ne pas être trop à côté) : En gros Zephyr ton problème c'est de trouver comment construire l'API Ajax serveur (ce que le serveur propose comme interface) sans que ce soit techniquement trop contraignant. Pour moi certains trucs à suivre seraient :

- De penser cette API (les "services") d'un point de vue plus modèle de données qu'interface graphique, puisque dans ton cas le couplage te pose problème. L'API ne correspond alors pas toujours exactement avec les évènements utilisateurs (clics et frappes), en fonction de l'UI et du modèle, il est possible de descendre un tas de données au cours d'un même appel mais les afficher bien plus tard.

- De regarder du côté des frameworks d'exposition de services PHP. Par exemple en Java, DWR permet d'exposer directement des objets Java en tant qu'objets Javascript et de ne pas se préoccuper des problèmes techniques d'exposition.

- Concernant les moteurs de templates, je ne sais pas ce qui est prévu pour Smarty, mais ca revient au point 1) : puisque l'API serveur ne peut pas être trop couplée à l'UI, pour permettre le remplacement sans conséquences d'un template, il faut la penser modèle de données. Le Javascript peut être mutualisé entre les templates si il y a suffisamment d'invariants entre eux (structure, id des tags, types des tags, ...), sinon il n'y a pas de choix que d'associer une version du Javascript à chaque template puisqu'il est intimement lié à l'UI (plus ou moins gênant en fonction de ce qui a été déporté côté browser).

Si ce problème de couplage entre l'interface et les appels asynchrones persiste, on peut toujours pousser le curseur à l'extrême côté client, en utilisant des frameworks réellement RIA tel que TIBCO General Interface (qui lui est du pur JavaScript), où là la création de l'HTML est entièrement réalisé côté browser (à partir d'un modèle de composant dans le cas de GI), et où les appels asynchrones sont de "vrais" web services n'ayant aucune connaissance de l'UI (éventuellement implémentés en SOAP, et contrairement à ce qu'on pourrait croire ça n'a pas l'air de ramer). L'effet de bord est que le développement (et surtout les tests) des règles métiers et de l'interface graphique sont entièrement séparés, ça rend les choses nettement plus simples et sûres.

TIBCO GI a l'air de partir d'une bonne idée, bien que complètement différente de l'approche que je voulais avoir (là encore il faut changer de conception, mais au moins celle-ci a l'avantage d'être saine et d'avoir une justification un peu plus solide que "il faut que ça marche en ajax").

Pour ce qui est du Javascript, j'ai tendance à le considérer comme un petit outil capable d'effectuer certaines tâches au niveau de la présentation, c'est en partie pour ça que je bloque avec l'implémentation actuellement requise pour la technologie ajax, qui utilise à mon avis Javascript pour faire des choses qui ne sont pas du tout de son domaine.

Bref, concevoir son site d'une façon un peu plus orientée objet pourrait être une solution effectivement : ça permet de faire autant de choses qu'avec des méthodes plus classiques, mais ça permet quand même d'intégrer de nouveaux éléments comme ajax de façon élégante. Mais ce serait supposer qu'il n'existe pas de solution "à mi-chemin" qui sans trop s'éloigner d'une conception classique permette quand même d'intégrer ajax sans conséquences trop lourdes sur le reste. La solution de spipu me semblait être une piste intéressante, reste à voir ce qu'on peut en tirer (j'ai un peu arrêté de réfléchir là dessus pour l'instant, je manque un peu de temps, mais j'y reviendrai surement ^^)