… widgets

Uhm, il y a quelques jours je me suis lancé à faire un petit widget pour LIFT07 que vous pouvez voir ci-contre (eh? pas encore inscrit? tu connais pas? go go go, fais un tour, ca vaut le détour).

Pour le placer sur un site il faut simplement copier un bout de code (hey, ne te presse pas encore à le faire ok? C’est juste un test), plus précisement il suffit d’insérer un petit iframe et le tour est joué, l’information affichée est générée dynamiquement via une page du site de la conférence.

Or, je me demande pourquoi tout ceux qui fournissent des widgets optent plutôt pour une inclusion dans le HTML d’un JavaScript qui s’occupe de tout?

Je ne comprends toujours pas les avantages d’une solution JS (qui va généralement insérer dynamiquement un iframe egalement) sur une solution brute HTML … si quelqu’un pourrait m’illuminer (ça se dit?)…

Merci


Tags: , , , ,

This entry was posted on Thursday, December 7th, 2006 at 12:51 pm and is filed under Programmation Web. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

10 Responses to “… widgets”

  1. Raphael Says:
    December 7th, 2006 at 3:44 pm

    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.

  2. Yoan Says:
    December 8th, 2006 at 10:03 pm

    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é).

  3. Mathieu Says:
    December 9th, 2006 at 11:47 am

    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…

  4. rortelli Says:
    December 9th, 2006 at 2:36 pm

    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?

  5. Mathieu Says:
    December 9th, 2006 at 6:52 pm

    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…

  6. Dom Says:
    December 12th, 2006 at 11:31 am

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

  7. robi Says:
    December 12th, 2006 at 12:19 pm

    @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.

  8. Dom Says:
    December 13th, 2006 at 9:52 am

    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.

  9. robi Says:
    December 13th, 2006 at 10:10 am

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

  10. gabyu Says:
    February 14th, 2007 at 6:46 pm

    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 ;)

    “

Leave a Reply