Comments on: … widgets

By: gabyu

gabyu — Wed, 14 Feb 2007 16:46:00 +0000

lu sur css4design.com :

”

L’élément IFRAME, dont la dénomination provient de la contraction d’inline frame signifie cadre en ligne ou encore cadre flottant.

Cet élément permet d’inclure des objets externes, y compris d’autres documents HTML. Il propose des fonctions similaires � la balise OBJECT.

Un des avantages de IFRAME est sa capacité � se comporter comme une cible pour d’autres liens. Ce qui peut être intéressant quand vous voulez que votre IFRAME affiche le résultat d’un script PHP, celui d’Eric Dupin par exemple.

Néanmoins, OBJECT est utilisable avec une DTD XHTML 1.0 Strict alors que ce n’est pas le cas pour IFRAME qui nécessitera la DTD XHTML 1.0 Transitional pour ne pas déclencher les foudres de Validator

L’IFRAME est donc un cadre flottant. C’est peut-être cette notion de cadre qui lui a fait du tort dans la communauté des intégrateurs. Je préfère pour ma part imaginer cette balise comme une balise SPAN qui aurait les super-pouvoirs combinés d’OBJECT et de FRAME.

Elle peut s’avérer indispensable quand vous intervenez dans une page en ASP et que vous voulez afficher le résultat d’une requête PHP/MySQL

“

By: robi

robi — Wed, 13 Dec 2006 08:10:31 +0000

Ca va donc Pas de problème de compatibilité en gros avec la majorité des navigateurs.

By: Dom

Dom — Wed, 13 Dec 2006 07:52:37 +0000

Extrait:
Browser Compatibility Note:

Inline Frames were introduced into the official specs in HTML 4. They started as an » Internet Explorer only tag, and so have been supported since IE3.0 and above.
Modern browsers such as » Firefox, » Safari and » Opera 4 also support them. Your only real trouble will come from that staple of the crap browser gang, Netscape 4, which skips over them as though they weren’t there.

By: robi

robi — Tue, 12 Dec 2006 10:19:00 +0000

@Mathieu: oui, c’est que le widget pour LIFT fait. Le script distant permet de changer l’information affichée avec un appel ajax a la base de données.

@Dom: ca existe? les iframes ne sont pas supportés par tous les navigateurs?

De manière générale, je pense que les deux possibilités qui s’offrent pour intégrer un widget sont similaires: la solution javascript va s’occuper de créer dynamiquement la “boîte” qui va contenir le widget, c’est-� -dire, générer le code HTML avec des DIV ou même un IFRAME ;). La solution IFRAME, � mon sens, étant la plus rapide � mettre en place, évitant d’avoir des problèmes de compatibilité CSS.

By: Dom

Dom — Tue, 12 Dec 2006 09:31:50 +0000

C’est peut-être aussi tout bêtement pour les navigateur qui ne gère pas le iframe! Une compatibilité propre et sans erreur.

By: Mathieu

Mathieu — Sat, 09 Dec 2006 16:52:55 +0000

Effectivement, mais dans le cas d’une page dynamique distante qui s’alimente d’une base de données et qui s’insère dans une iframe, tu vas devoir recharger toute ta page web pour actualiser le contenu dynamique de ton iframe. Dans le cas d’un Javascript il n’est pas nécessaire de recharger toute la page web pour actualiser le widget…le propre Javascript s’en occupe via XML-RPC…
Il est cependant vrai que beaucoup de widgets utilisent Javascript sans que ce soit pour autant 100% nécessaire…

By: rortelli

rortelli — Sat, 09 Dec 2006 12:36:30 +0000

Uhm, oui, mais en utilisant un iframe, j’appelle un fichier distant qui lui se peuple dynamiquement avec une base de données distante. A mon sens, pour l’instant, il n’y a pas de commentaire répondant � ma question… ou j’ai mal interprété vos propos?

By: Mathieu

Mathieu — Sat, 09 Dec 2006 09:47:11 +0000

Si une base de donnée en backend maintient de l’information liée ou utilisée par le widget importé, javascript permet de récupérer cette information, le pure HTML non…C’est le principe d’Ajax…

By: Yoan

Yoan — Fri, 08 Dec 2006 20:03:59 +0000

avoir des informations sur la page parente de ton iframe, rien que pour afficher ton widget d’une taille adéquate par exemple, où même écrire directement dans la page courante (ce qui n’est pas bien compliqué).

By: Raphael

Raphael — Thu, 07 Dec 2006 13:44:38 +0000

un url de js ou un url de page, quelles différences ? Aucune si ce n’est que la méthode d’appel par js est une couche en dessus du iFrame. Donc cela devrait permettre d’être plus souple. Dans les deux cas, on a une fragilité lié au chemin sur le répertoire du script ou de la page correspondante. Un cordon a toujours certaines limitations. J’imagine que le mieux serait d’avoir un url permanent avec des paramètres � faire transiter.

Ça complique encore plus le processus. Mais ça permet de poser une DB qui reroute et éventuellement track le tout.