Widget - Iframe vs JavaScript
Je dois développer un widget qui sera utilisé par un site tiers. Ce n'est pas une application à déployer sur un site de réseautage social. Je peux donner aux gars du site un lien à utiliser comme le src d'un iframe ou je peux le développer comme une requête JavaScript.
Quelqu'un peut-il me dire les compromis entre les 2 approches (IFrame contre JS)?
Je cherchais sur la même question et j'ai trouvé cet article intéressant:
http://prettyprint.me/prettyprint.me/2009/05/30/widgets-iframe-vs-inline/
Les widgets sont de petites applications Web qui peuvent facilement être ajoutées à n'importe quelle page Web. Ils sont parfois appelés gadgets et sont largement utilisés dans un nombre croissant de pages Web, de blogs, de sites sociaux, de pages d'accueil personnalisées telles que iGoogle, mon Yahoo, netvibes, etc. Dans ce blog, j'utilise plusieurs widgets, tels que le compteur RSS à droite. qui affiche le nombre d'utilisateurs abonnés à ce blog (ne vous inquiétez pas, il va grandir, c'est un nouveau blog ;-)). Les widgets sont excellents dans le sens où ils sont de petites fonctionnalités réutilisables que même les non-programmeurs peuvent utiliser pour enrichir leur site.
Au fil du temps, j'ai écrit plusieurs de ces widgets, à la fois des widgets "bruts" qui peuvent être intégrés dans n'importe quel site, ainsi que des gadgets iGoogle qui sont plus structurés, worpress *, clavier et widgets de blogueur, donc je suis heureux de partager mon expérience.
En tant qu'auteur de widgets, pour les widgets qui s'exécutent côté client (simple code HTML intégrable), vous avez le choix d'écrire votre widget dans un iframe ou simplement d'aligner la page et de l'intégrer au dom de la page d'hébergement. Le reste de l'article traite des avantages et des inconvénients des deux méthodes.
Comment cela se fait-il techniquement? Comment utiliser un iframe ou comment implémenter un widget en ligne?
Les iframes sont un peu plus faciles à implémenter. L'exemple suivant affiche un widget iframe simple: http://my-great-widget.com/widgwt 'width = "100" height = "100" frameborder =' 0 '>
frameborder = ’0’ est utilisé pour s’assurer que les ifrmae n’ont pas de bordure, ce qui leur donne un aspect plus naturel sur la page. http://my-great-widget.com/widget est chargé de diffuser le contenu du widget sous forme de page HTML complète.
Les gadgets en ligne peuvent ressembler à ceci:
function createMyWidgetHtml () {return "Bonjour le monde des widgets"; } document.getElementById ('myWidget'). innerHTML = createMyWidgetHtml (); Comme vous pouvez le voir, la fonction createMyWidgetHtml () est responsable de la création du contenu réel du widget et n'a pas nécessairement à parler à un serveur pour ce faire. Dans l'exemple iframe, il doit y avoir un serveur. Dans l'exemple en ligne, il n'est pas nécessaire d'avoir un serveur, bien que si nécessaire, il est possible d'obtenir des données du serveur, ce qui est en fait un cas très courant, les widgets appellent généralement le code côté serveur. L'utilisation du code côté serveur de la méthode en ligne est invoquée au moyen du javascript on-demmand.
Donc, pour résumer, dans le cas de l'iframe, nous plaçons simplement un code HTML iframe et pointons la source de l'iframe vers un emplacement de serveur qui sert réellement le contenu du widget. Dans le cas en ligne, nous créons le contenu localement en utilisant javascript. Vous pouvez bien sûr combiner l'utilisation d'iframe avec javascript ainsi que l'utilisation de la méthode inline avec les appels côté serveur, vous n'êtes pas limité par cela, mais les chemins commencent différemment.
Alors, quel est le gros problème? Quelle est la différence? Il existe plusieurs différences importantes, alors commence ici la partie intéressante de l'article.
Sécurité. Les widgets iFrame sont plus sécurisés.
Quels risques les gadgets imposent-ils et qui est réellement en danger? L'utilisateur du site et la réputation du site sont en danger.
Avec les gadgets en ligne, le navigateur pense que la source du code du gadget provient du site d'hébergement. Supposons que vous parcourez votre application de messagerie préférée http://my-wonderful-email.com et cette application de messagerie a installé un widget qui affiche une horloge de http: // great -clock-widgets.com/ . Si ces widgets sont implémentés en tant que widget en ligne, le navigateur pense que le code du widget provient de my-wonderful-email.com et non de great-clock-widgets.com et il permettra donc au code du widget d'accéder finalement aux cookies appartenant à my-wonderful-email.com et l'auteur malveillant du widget volera votre e-mail. Il est important de se rendre compte que les navigateurs ne se soucient pas de l'emplacement du fichier javascript; tant que le code s'exécute sur le même cadre, le navigateur considère que tout le code est d'origine sur le domaine du cadre. Ainsi, en tant qu'utilisateur, vous êtes blessé en perdant le contrôle de votre compte de messagerie et my-wonderful-email est blessé en perdant sa réputation.
Si la même horloge aurait été implémentée dans un iframe et que la source iframe est différente de la source de la page (ce qui est le cas commun, par exemple, la source de la page est my-wonderful-email.com et la source du gadget est great-clock-widgets .com), le navigateur n'autoriserait pas les widgets d'horloge à accéder aux cookies de la page, ni à aucune autre partie du document d'hébergement, y compris la page d'accueil dom. C’est beaucoup plus sûr. En fait, les pages d'accueil personnelles telles que iGoogle n'autorisent même pas les gadgets en ligne, seuls les gadgets iframe sont autorisés. (les gadgets en ligne ne sont autorisés que dans de rares cas, uniquement après une inspection approfondie par l'équipe iGoogle pour s'assurer qu'ils ne sont pas malveillants)
Pour résumer, les widgets iframe sont bien plus sûrs. Cependant, leur fonctionnalité est également beaucoup plus limitée. Ensuite, nous allons discuter de ce que vous perdez en fonctionnalités.
Look and feel Dans la bataille de look and feel, les gadgets en ligne (généralement **) gagnent. La bonne chose à leur sujet est qu'ils peuvent être faits pour faire partie de la page. Ils peuvent hériter des styles CSS de la page, y compris les polices, les couleurs, la taille du texte, etc. Si les cadres, OTHO doivent définir leur CSS à partir de zéro, il est donc assez difficile pour eux de bien se fondre dans la page.
Mais ce qui est encore plus important, c'est que les iframes doivent déclarer leur taille. Lorsque vous ajoutez un iframe à une page, vous devez inclure une propriété width et height et si vous ne le faites pas, le navigateur utilisera certains paramètres par défaut. Maintenant, si votre widget est un widget d'horloge qui est assez facile b/c, vous savez exactement quelle taille vous voulez qu'il soit, mais dans de nombreux cas, vous ne savez pas à l'avance combien d'espace votre widget va prendre. Si, par exemple, vous créez un widget qui affiche une liste quelconque et vous ne savez pas combien de temps cette liste va être ou quelle largeur chaque élément va être. Habituellement, en HTML, ce n'est pas grave car le HTML est un langage déclaratif, donc tout ce que vous devez faire est de dire au navigateur ce que vous voulez afficher et le navigateur trouvera une disposition raisonnable pour cela, mais avec iframe, ce n'est pas le Cas; avec les ifrmaes, les navigateurs exigent que vous lui disiez exactement quelle est la taille de l'iframe et qu'il ne le trouvera pas par lui-même. C'est un vrai problème pour les auteurs de widgets qui souhaitent utiliser des iframes - si vous avez besoin de trop d'espace, la page comportera des vides et si vous spécifiez trop peu, la page aura des barres de défilement, Dieu ne plaise pas.
Regardez et sentez-vous sage, gagne en ligne. Mais notez que cela dépend vraiment de votre application de widget. Si tout ce que vous voulez faire, c'est une horloge, vous pouvez aussi vous entendre avec une iframe.
Les IFrmaes côté serveur et côté client nécessitent que vous spécifiiez une URL src. Ainsi, lorsque vous implémentez un widget à l'aide d'un iframe, vous devez disposer d'un code côté serveur. Cela pourrait être à la fois une limitation et un casse-tête pour certains (posséder un serveur, un nom de domaine, etc., gérer la charge, payer des factures de réseau, etc.) mais pour d'autres, c'est en fait un point en faveur des iframes b/c, cela vous permet d'écrire complètement votre widgets dans les technologies côté serveur, vous pouvez donc écrire une grande partie du code et en fait presque tout en utilisant votre technologie côté serveur préférée, que ce soit asp.net, Django, ror, jsp, struts, Perl ou d'autres dinosaures. Lors de la mise en œuvre d'un gadget en ligne, vous vous retrouverez de plus en plus à pratiquer votre javascript Ninja.
Quel est l'algorithme de décision alors? Auteurs de widgets: si le widget peut être implémenté comme un iframe, préférez un iframe simplement pour préserver la sécurité et la confiance des utilisateurs. Si un widget nécessite une mise en ligne (et le support le permet, par exemple, pas iGoogle et ses amis), utilisez en ligne mais n'osez pas exploiter la confiance des utilisateurs!
Installateurs de widgets: lorsque vous installez un widget dans votre blog, vous ne voyez pas de ruban "sans danger pour les utilisateurs" sur les widgets. Comment savoir si le widget est sûr ou non? Il y a deux alternatives que je peux suggérer: 1) faire confiance au vendeur 2) lire le code. Soit vous faites confiance au fournisseur de widgets et vous l'installez quand même, soit vous prenez le temps de lire son code et de déterminer vous-même s'il est fiable ou non. La réalité est que la plupart des propriétaires de sites ne prennent pas la peine de lire le code ou ne sont même pas conscients du risque auquel ils exposent leurs utilisateurs, et les fournisseurs de widgets sont donc aveuglément fiables. Dans de nombreux cas, ce n'est pas un problème car les blogs ne contiennent généralement pas d'informations personnelles sur leurs lecteurs. Je soupçonne que les choses commenceront à changer une fois qu'il y aura peu d'exploits de haut niveau (et j'espère que cela n'arrivera jamais).
Utilisateurs: les utilisateurs sont gardés dans le noir. Tout comme il n'y a pas de rubans "sans danger pour les utilisateurs" sur les propriétaires de sites de widgets installés, il n'y a pas de sites "sans danger" et, fondamentalement, les utilisateurs sont tenus dans l'ignorance et n'ont aucune idée, même s'ils ont les compétences techniques, qu'ils soient ou non le site qu'ils utilisent contient des widgets, qu'ils soient en ligne ou non et qu'ils soient malveillants. Bien qu'en théorie, un développeur qualifié puisse inspecter le code à l'avance, avant de l'exécuter dans son navigateur et de perdre son compte de messagerie à un pirate, mais ce n'est pas pratique et il ne faut pas s'attendre à ce que les utilisateurs en masse le fassent. IMO, c'est une condition malheureuse et j'espère seulement que les attaquants ne trouveront pas un moyen d'en profiter et Doom la merveilleuse culture des widgets ouverts sur le Web.
Heureux les gens de widgets!
- Certaines plates-formes de blogs ont des structures quelque peu différentes pour les widgets et elles peuvent parfois avoir à la fois des widgets et des plugins qui peuvent être corrélés dans leur fonctionnalité, mais pour le sujet de la discussion ici, je vais utiliser le terme widget pour parler du type "brut" qui se compose de code javascript côté client ** Bien que dans la plupart des cas, vous souhaitiez que les widgets héritent des styles de la page d'hébergement pour les rendre cohérents, parfois vous ne voulez pas que le widget hérite des styles de la page, donc dans dans ce cas, les iFrames vous permettent de démarrer votre CSS à partir de zéro.
Pourquoi ne pas faire les deux?
Je préfère proposer aux sites tiers un script comme:
<script type="text/javascript" src="urlToYourScript"></script>
le fichier sur votre serveur ressemble à:
document.writeln('<iframe src="pathToYourWidget"
name="MagicIframe" width="300" height="600" align="left" scrolling="no"
marginheight="0" marginwidth="0" frameborder="0"></iframe>');
METTRE À JOUR:
un inconvénient de l'utilisation d'une iframe qui pointe vers une URL sur votre serveur est que vous ne générez pas un "vrai" backlink si quelqu'un clique sur une URL de votre serveur pointant vers votre serveur.
Je suis sûr que de nombreux développeurs/propriétaires de sites apprécieraient une solution Javascript qu'ils peuvent adapter à leurs besoins plutôt que d'utiliser un iframe. Si j'allais inclure un composant d'un tiers, je préfère le faire via Javascript car j'aurais plus de contrôle.
En ce qui concerne la facilité d'utilisation, les deux sont similaires en termes de simplicité, donc pas de réel compromis là-bas.
Une autre pensée, assurez-vous d'obtenir un certificat SSL pour le domaine sur lequel vous l'hébergez et écrivez la déclaration include en conséquence si la page est servie via SSL. Si les propriétaires de votre site ont une raison d'utiliser SSL, ils l'apprécieront certainement, car Firefox et d'autres navigateurs se plaindront lorsqu'une page est servie avec un mélange de contenu sécurisé/non sécurisé.
Si le widget peut être intégré dans un iframe, ce sera mieux pour les performances frontales du site d'hébergement car les iframes ne bloquent pas le téléchargement de contenu. Cependant, comme d'autres l'ont fait remarquer, l'utilisation d'iframes présente d'autres inconvénients.
Si vous implémentez en javascript, veuillez considérer meilleures pratiques de performances frontales lors du développement. En particulier, vous devriez regarder Chargement javascript non bloquant . Google Analytics et d'autres fournisseurs de widgets tiers prennent en charge cette méthode de chargement. Il serait également utile de charger le javascript en bas de la page.
Ravi de savoir qu'il ne doit pas être déployé dans un site de réseautage social ... qui laisse simplement le reste du Web ;-)
Ce qui serait le plus utile dépend de votre widget. Les IFrames et javascript ont généralement des objectifs très différents et peuvent être mélangés (c'est-à-dire javascript dans un iframe ou javascript créant un iframe).
- IFrames a eu des problèmes de dimensionnement; s'il est censé correspondre exactement à la page, savez-vous qu'il s'affiche de la même manière sur tous les navigateurs, les données ne déborderont pas de son conteneur, etc.?
- Les IFrames sont simples. Il peut s'agir d'une simple page HTML statique.
- Lorsque vous utilisez des IFrames, vous exposez votre widget très clairement.
- Mais là encore, pourquoi ne pas avoir votre site tiers simplement inclure le HMTL à une URL donnée? Le HTML peut ensuite être étendu pour contenir du javascript quand/si vous en avez besoin.
- Le Javascript pur permet plus de flexibilité mais au prix d'une certaine complexité.
Le gros plus des iframes: tous les CSS et JS sont séparés de la page Host, donc votre CSS existant ne fonctionne que. (Si vous souhaitez que le site hôte modélise votre contenu en fonction, c'est bien sûr un inconvénient.)
Le gros moins des iframes: ils ont une largeur et une hauteur fixes et des barres de défilement apparaîtront si votre contenu est plus grand.