Je dois développer un widget qui sera utilisé par un site tiers. Ce n'est pas une application à déployer dans un site de réseau social. Je peux donner aux gars du site un lien pour être utilisé comme src d'un iframe ou je peux le développer comme une requête JavaScript. Est-ce que quelqu'un peut me dire le compromis entre les 2 approches (IFrame versus JS)?Widget - Iframe versus JavaScript
bon de savoir qu'il est de ne pas être déployé dans un site de réseautage social ... qui laisse simplement le reste du web ;-)
Quel serait le plus utile dépend de votre widget. Les IFrames et javascript servent 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).
je cherchais au sujet de la même question et j'ai trouvé cet article intéressant:
http://prettyprint.me/prettyprint.me/2009/05/30/widgets-iframe-vs-inline/
Widgets sont de petites applications web qui peuvent facilement être ajoutés à une page Web . Ils sont parfois appelés Gadgets et sont largement utilisés dans le nombre croissant de pages Web, blogs, sites sociaux, pages d'accueil personnalisées telles que iGoogle, Yahoo, netvibes, etc. Dans ce blog, j'utilise plusieurs widgets , tels que le compteur RSS à droite qui affiche combien d'utilisateurs sont abonnés à ce blog (ne vous inquiétez pas, ça va grandir, c'est un nouveau blog ;-)). Widgets sont grands dans le sens où ils sont petites fonctionnalité réutilisable que même les non-programmeurs peuvent utiliser pour enrichir leur site.
J'ai écrit plusieurs de ces widgets sur le temps les deux widgets « premières » qui peuvent s'intégrés dans un site ainsi que des gadgets iGoogle qui sont plus structurés, worpress *, TypePad et widgets blogueur, donc je suis heureux de partager mon expérience.
En tant qu'auteur widget, pour les widgets qui tournent sur le côté client (simple, code HTML intégrable) vous avez le choix d'écrire votre widget l'intérieur d'un iframe ou simplement inline la page et faire partie du Royaume de la page d'hébergement. Le reste de la publication traite des avantages et inconvénients des deux méthodes.
Comment cela se passe-t-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 rend simple widget iframe: http://my-great-widget.com/widgwt 'width = "100" height = "100" frameborder = '0'>
frameborder =' 0 " est utilisé pour s'assurer que l'ifrmae n'a pas de bordure donc il semble plus naturel sur la page. Le http://my-great-widget.com/widget est chargé de servir le contenu du widget en tant que page HTML complète.
gadgets Inline pourrait ressembler à ceci:
fonction createMyWidgetHtml() {return "Bonjour tout le monde de widgets"; } document.getElementById ('myWidget'). InnerHTML = createMyWidgetHtml(); Comme vous pouvez le voir, la fonction createMyWidgetHtml() responsable de créant le contenu du widget réel et ne doit pas nécessairement parler à un serveur pour le faire. Dans l'exemple iframe, il doit y avoir un serveur . Dans l'exemple inline il n'y a pas besoin d'être un serveur, bien que si nécessaire, il est possible d'obtenir des données du serveur, qui est en fait un cas très commun, les widgets appellent généralement le code côté serveur . L'utilisation du code côté serveur de la méthode inline est invoquée au moyen de on-demmand javascript.
Donc, pour résumer, dans le cas iframe nous plaçons simplement un code iframe HTML et point la source de l'iframe à un emplacement qui sever sert en fait le contenu du widget. Dans le cas inline, nous créons le contenu localement en utilisant javascript . Vous pouvez bien sûr combiner utilisation de iframe avec javascript ainsi que l'utilisation de la méthode en ligne avec les appels côté serveur, vous n'êtes pas limité par cela, mais les chemins commencent différemment.
Alors, quel est le problème? Quelle est la différence? Il existe plusieurs différences importantes, donc commence ici la partie intéressante de la publication .
Sécurité. Les widgets iFrame sont plus sécurisés.
Quels risques les gadgets imposent-ils et qui est-il réellement mis en péril? L'utilisateur du site et la réputation du site sont en danger.
Avec les gadgets intégrés, le navigateur pense que la source du gadget provient du site hébergeur. 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 sous la forme d'un 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 donc permet au code du widget d'avoir finalement accès aux cookies appartenant à my-wonderful-email.com et l'auteur diabolique du widget va voler votre email . Il est important de se rendre compte que les navigateurs ne se soucient pas de savoir où le fichier javascript est hébergé ; Tant que le code s'exécute sur la même trame , le navigateur considère tout le code comme originationg sur le domaine . Donc, vous en tant qu'utilisateur se blesser en perdant le contrôle de votre compte e-mail et my-wonderful-email se blesse en perdant sa réputation.
Si la même horloge aurait obtenu mis en place à l'intérieur d'un iframe et 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 le gadget source est great-clock-widgets.com) alors le navigateur ne permettrait pas aux widgets d'horloge d'accéder aux cookies de la page, ni à l'accès à toute autre partie du document d'hébergement, y compris la page d'accueil dom. C'est beaucoup plus sûr. En fait, les pages personnelles telles que iGoogle ne permettent même pas les gadgets en ligne, seuls les gadgets iframe sont autorisés. (Gadgets en ligne sont autorisés que dans des cas rares, qu'après inspection approfondie par l'équipe iGoogle pour vous assurer que ils ne sont pas malveillants)
En résumé, les widgets iFrame sont beaucoup plus sûr. Cependant, ils sont aussi beaucoup plus limités en fonctionnalités. Ensuite, nous allons discuter de ce que vous perdez en fonctionnalité .
Apparence et sensations Dans l'apparence et la convivialité de la bataille, les gadgets en ligne (habituellement **) gagnent. La bonne chose à leur sujet est qu'ils peuvent être faits pour ressembler à partie de la page. Ils peuvent hériter des styles CSS de la page, y compris polices, couleurs, taille du texte etc. Iframes, OTHO doit définir leur CSS de les motifs de sorte qu'il est assez difficile pour eux de se fondre bien dans la page .
Mais ce qui est encore plus important est que les iframes doivent déclarer quelle sera leur taille . Lorsque vous ajoutez un iframe à une page, vous devez inclure une largeur et une propriété height et si vous ne le faites pas, le navigateur utilisera certains paramètres par défaut. Maintenant, si votre widget est un widget 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 est va prendre . Si, par exemple, vous créez un widget qui affiche une liste de quelque sorte et vous ne savez pas combien de temps cette liste va à être ou la largeur de chaque élément va être. Habituellement en HTML ce n'est pas un gros problème parce que HTML est un langage basé sur des déclarations donc tout ce dont vous avez besoin est de dire au navigateur ce que vous voulez afficher et le navigateur va trouver une mise en page raisonnable pour cela, mais avec iframe this n'est pas le cas; avec les navigateurs ifrmaes, il faut que vous lui disiez exactement quelle est la taille de l'iframe et elle ne le comprendra pas tout seul. Ce est un vrai problème pour les auteurs de widgets qui veulent utiliser des iframes - si vous avez besoin de trop d'espace, la page aura des vides et si vous spécifiez trop peu la page aura des barres de défilement, dieu interdit.
Regardez et sentez sage, gagne en ligne. Mais notez que cela dépend vraiment de votre application de widget. Si tout ce que vous voulez faire est une horloge, vous pouvez obtenir avec un iframe tout aussi bien.
côté serveur par rapport IFrmaes côté client vous avez besoin de spécifier une URL src si lors de la mise en œuvre d'un widget en utilisant un iframe vous devez avoir un code côté serveur .Cela pourrait aussi bien être une limitation et un mal de tête à certains (posséder un serveur , nom de domaine, etc., traitant de la charge, le paiement des factures de réseau, etc.) mais à d'autres c'est en fait un point en faveur des iframes b/c il nous a laissés vous écrire complètement vos widgets dans les technologies côté serveur, de sorte que vous pouvez écrire beaucoup de code et en fait presque tout en utilisant votre technologie serveur côté favori que ce soit asp.net, django, ror, jsp, struts, perl ou autres dinosaures. Lors de l'implémentation d'un gadget en ligne , vous vous retrouverez de plus en plus en train de pratiquer votre javascript Ninja.
Quel est l'algorithme de décision alors? Widget auteurs: Si le widget peut être implémenté en tant que iframe, préférez un Iframe simplement pour préserver la sécurité des utilisateurs . Si un widget nécessite une mise en ligne (et que le support permet, par exemple, pas iGoogle et ses amis) d'utiliser inline mais n'osent pas exploiter les utilisateurs, faites confiance à ! Installateurs Widget: Lors de l'installation d'un widget dans votre blog, vous ne voyez pas un ruban "sécurisé pour les utilisateurs" sur les widgets. Comment pouvez-vous savoir si le widget est sûr ou non? Il existe deux alternatives que je peux suggérer: 1) confiance au vendeur 2) lire le code. Soit vous faites confiance au fournisseur de widget et l'installer quand même ou vous prenez le temps de lire son code et de déterminer vous-même si c'est digne de confiance ou non. La réalité est que la plupart des propriétaires de site ne prennent pas la peine de lire le code ou ne sont même pas conscients du risque auquel ils sont exposés, et les fournisseurs de gadgets sont donc approuvés. 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 vont commencer à changer une fois qu'il y aura quelques exploits de haut profil (et j'espère que ça n'arrivera jamais).
Utilisateurs: Les utilisateurs sont tenus dans le noir. Tout comme il n'y a pas « sans danger pour utilisateurs » rubans widgets propriétaires de sites installent, il n'y a pas « sûr utilisation » des sites et essentiellement les utilisateurs sont conservés dans l'obscurité et ont aucune idée, même si elles ont les compétences techniques, si le site qu'ils utilisent contient des widgets, si les widgets sont en ligne ou non et s'ils sont malveillants. Bien qu'en théorie un développeur qualifié peut inspecter le code à l'avance, avant de l'exécuter dans son navigateur et de perdre son compte e-mail à un hacker, mais ce n'est pas pratique et il devrait pas attendre que les utilisateurs en masse vont faire . IMO c'est une condition malheureuse et j'espère que les attaquants ne trouveront pas un moyen d'en profiter et de condamner la merveilleuse culture ouverte du widget sur le web.
Heureux les gens du widget!
- Certaines plates-formes de blog ont une structure quelque peu différentes pour les widgets et ils peuvent parfois avoir les widgets et plugins qui peuvent établir une corrélation entre dans leur fonctionnalité, mais pour la question de la discussion ici je vais lously utiliser le widget terme pour discuter du type « brut » qui se compose de côté client code javascript ** Bien que dans la plupart des cas, vous auriez souhaitez que les widgets héritent des styles de la page d'accueil pour les rendre compatibles avec elle, parfois vous vraiment ne voulez pas le widget pour hériter des styles de la page, donc dans ce cas iFrames vous permet de démarrer votre CSS à partir de zéro.
Je suis sûr que de nombreux développeurs/propriétaires de sites apprécieraient une solution Javascript qu'ils peuvent le style à leurs besoins plutôt que d'utiliser un iframe. Si j'allais inclure un composant d'un tiers, je préférerais le faire via Javascript car j'aurais plus de contrôle.
En ce qui concerne la facilité d'utilisation, les deux sont similaires dans la simplicité, donc pas de véritable compromis là-bas.
Une autre idée, assurez-vous que vous obtenez un certificat SSL pour le domaine que vous hébergez sur ce et écrire l'instruction include en conséquence si la page est servie sur SSL. Dans le cas où les propriétaires de votre site ont une raison d'utiliser SSL, ils apprécieraient sûrement cela, car Firefox et d'autres navigateurs vont se plaindre quand une page est servie avec un mélange de contenu sécurisé/non sécurisé.
Si le widget peut être incorporé dans un iframe, il sera préférable pour les performances frontend du site d'hébergement car les iframes ne bloquent pas le téléchargement de contenu. Cependant, comme d'autres l'ont remarqué, il y a d'autres inconvénients à utiliser les iframes.
Si vous mettez en œuvre en javascript, veuillez considérer frontend performance best practices lors du développement. En particulier, vous devriez regarder Non blocking javascript loading. Google Analytics et d'autres fournisseurs de widgets tiers prennent en charge cette méthode de chargement. Il serait également utile si vous pouvez charger le javascript au bas de la page.
Pourquoi ne pas faire les deux?
Je préfère offrir des sites tiers un script comme:
<script type="text/javascript" src="urlToScript"></script>
le fichier sur votre serveur ressemble à:
document.writeln('<iframe src="pathToYourGroovyWidget"
name="MagicIframe" width="300" height="600" align="left" scrolling="no"
marginheight="0" marginwidth="0" frameborder="0"></iframe>');
MISE À JOUR:
le grand inconvénient d'utiliser une iframe cela pointe vers une URL sur votre serveur, c'est que vous ne générez pas de backlink "réel" si quelqu'un clique sur une URL de votre serveur pointant vers votre serveur.
Le gros plus des iframes: tous les CSS et JS sont séparés de la page hôte, donc votre CSS existant fonctionne. (Si vous voulez que le site hôte adapte votre contenu, c'est bien sûr moins.)
Le gros minus des iframes: ils ont une largeur et une hauteur fixes et des barres de défilement apparaîtront si votre contenu est plus grand .
Un autre avantage que je pourrais voir à l'utilisation d'un iFrame sur JavaScript est que tout CSS ou Javascript requis serait autonome et n'interférerait pas avec le site web appelant. Bien sûr, vous pouvez facilement contourner ce problème en utilisant des sélecteurs non génériques. – Noz
dans un iframe vous pouvez utiliser SLL, en javascript le site parent doit avoir installé ssl. –