ウィジェット-iframeとJavaScript
サードパーティのサイトで使用されるウィジェットを開発する必要があります。これは、ソーシャルネットワーキングサイトに展開されるアプリケーションではありません。 iframeのsrcとして使用するリンクをサイトに提供するか、JavaScriptリクエストとして開発できます。
誰かが2つのアプローチ（IFrameとJS）のトレードオフを教えてもらえますか？
私は同じ質問を探していましたが、この興味深い記事を見つけました。
http://prettyprint.me/prettyprint.me/2009/05/30/widgets-iframe-vs-inline/
ウィジェットは、任意のWebページに簡単に追加できる小さなWebアプリケーションです。ガジェットと呼ばれることもあり、ますます多くのWebページ、ブログ、ソーシャルサイト、iGoogle、My Yahoo、Netvibesなどのパーソナライズされたホームページで使用されています。このブログでは、右側のRSSカウンターなど、いくつかのウィジェットを使用していますこれは、このブログを購読しているユーザーの数を表示します（心配しないで、成長します、それは新しいブログです;-)）。ウィジェットは、プログラマーでなくてもサイトを充実させるために利用できる、再利用可能な小さな機能であるという意味で優れています。
私はそのようなウィジェットを時間とともにいくつかのサイトに埋め込むことができる「生の」ウィジェットと、より構造化されたworpress *、タイプパッド、およびブロガーのウィジェットであるiGoogleガジェットの両方を作成しました。
ウィジェット作成者として、クライアント側で実行されるウィジェット（単純な埋め込み可能なHTMLコード）の場合、ウィジェットをiframe内に記述するか、単にページをインライン化し、ホスティングページのdomの一部にするかを選択できます。ポストの残りでは、両方の方法の長所と短所について説明します。
技術的にはどうですか？ iframeの使用方法またはインラインウィジェットの実装方法
Iframeの実装はいくぶん簡単です。次の例では、単純なiframeウィジェットをレンダリングします。http：//my-great-widget.com/widgwt 'width = "100" height = "100" frameborder =' 0 '>
frameborder = ’0’は、ページに自然に見えるようにifrmaeに境界線がないことを確認するために使用されます。 http://my-great-widget.com/widget は、完全なHTMLページとしてウィジェットコンテンツを提供する役割を果たします。
インラインガジェットは次のようになります。
function createMyWidgetHtml（）{return "Hello world of widgets"; } document.getElementById（ 'myWidget'）。innerHTML = createMyWidgetHtml（）;ご覧のとおり、関数createMyWidgetHtml（）は、実際のウィジェットコンテンツを作成する役割を果たし、必ずしもサーバーと通信する必要はありません。 iframeの例では、サーバーが必要です。インラインの例では、サーバーは必要ありませんが、必要に応じてサーバーからデータを取得することができます。これは実際には非常に一般的なケースであり、ウィジェットは通常サーバー側のコードを呼び出します。インラインメソッドの使用サーバー側コードは、オンデマンドJavaScriptによって呼び出されます。
要約すると、iframeの場合、iframe HTMLコードを配置し、iframeのソースを実際にウィジェットのコンテンツを提供するサーバーの場所に向けます。インラインの場合、javascriptを使用してコンテンツをローカルに作成します。もちろん、iframeの使用とJavaScriptを組み合わせたり、サーバー側の呼び出しでインラインメソッドを使用したりすることもできますが、それによって制限されることはありませんが、パスは異なって始まります。
それで、大したことは何ですか？違いは何ですか？いくつかの重要な違いがあるので、ここから投稿の興味深い部分を開始します。
セキュリティ。 iFrameウィジェットはより安全です。
ガジェットはどのようなリスクを課し、実際に誰がリスクにさらされていますか？サイトのユーザーとサイトの評判は危険にさらされています。
インラインガジェットでは、ブラウザはガジェットコードコードのソースがホスティングサイトから来ていると考えます。お気に入りのメールアプリケーションを閲覧していると仮定しましょう http://my-wonderful-email.com と、このメールアプリケーションは http：// greatから時計を表示するウィジェットをインストールしました-clock-widgets.com/ 。そのウィジェットがインラインウィジェットとして実装されている場合、ブラウザはウィジェットのコードがgreat-clock-widgets.comではなくmy-wonderful-email.comから発信されたと見なし、ウィジェットのコードが最終的にCookieにアクセスできるようにしますmy-wonderful-email.comが所有しており、ウィジェットの悪人があなたのメールを盗みます。ブラウザはJavaScriptファイルがホストされている場所を気にしないことを理解することが重要です。コードが同じフレームで実行されている限り、ブラウザはすべてのコードをフレームのドメインのorigingとみなします。そのため、ユーザーとしてのあなたはあなたのメールアカウントのコントロールを失うことで傷つき、私の不思議なメールは評判を失うことで傷つきます。
同じクロックがiframe内に実装され、iframeソースがページソースと異なる場合（一般的なケースです。たとえば、ページソースはmy-wonderful-email.comで、ガジェットソースはgreat-clock-widgetsです.com）を使用すると、ブラウザは時計ウィジェットからページCookieへのアクセスを許可せず、ホストページdomを含むホスティングドキュメントの他の部分へのアクセスも許可しません。より安全です。実際のところ、iGoogleなどの個人のホームページではインラインガジェットも許可されておらず、iframeガジェットのみが許可されています。 （インラインガジェットは、まれにしか許可されません。iGoogleチームが悪意のないことを確認するために徹底的に検査した後にのみ許可されます）
要約すると、iframeウィジェットはより安全です。ただし、それらは機能が制限されています。次に、機能で失うものについて説明します。
ルックアンドフィールルックアンドフィールでは、バトルインラインガジェット（通常**）が勝ちます。それらの良いところは、ページの一部として見えるようにできることです。フォント、色、テキストサイズなどを含むCSSスタイルをページから継承できます。iframe、OTHOはCSSをゼロから定義する必要があるため、ページにうまく溶け込むのはかなり困難です。
しかし、さらに重要なことは、iframeがそのサイズを宣言する必要があるということです。 iframeをページに追加する場合、幅と高さのプロパティを含める必要があり、含めない場合、ブラウザはデフォルト設定を使用します。さて、ウィジェットが時計ウィジェットであれば、どのくらいのサイズにしたいのかを正確に知っていますが、多くの場合、ウィジェットがどれだけのスペースを取るかは事前にはわかりません。たとえば、ある種のリストを表示するウィジェットを作成していて、このリストの長さや各アイテムの幅がわからない場合。 HTMLは通常、宣言ベースの言語であるため、これは大したことではありません。したがって、表示するものをブラウザに指示するだけで、ブラウザは適切なレイアウトを見つけ出しますが、iframeでは、場合; ifrmaesブラウザでは、iframeのサイズを正確に伝える必要があり、それだけでは判断できません。これは、iframeを使用したいウィジェット作成者にとって本当の問題です。スペースを必要とする場合、ページにボイドがあり、ページの指定が少なすぎると、スクロールバーが表示されます。
賢く見て、インラインで勝ちます。ただし、これは実際にウィジェットアプリケーションに依存することに注意してください。時計だけが必要な場合は、iframeを使用することもできます。
サーバー側とクライアント側のIFrmaesでは、src URLを指定する必要があるため、iframeを使用してウィジェットを実装する場合、サーバー側のコードが必要です。これはいくつかの制限と頭痛の種になる可能性があります（サーバーの所有、ドメイン名など、負荷の処理、ネットワークの請求書の支払いなど）が、他の人にとってこれは実際にiframeを支持するポイントです。 asp.net、Django、ror、jsp、struts、Perl、その他の恐竜など、お気に入りのサーバー側テクノロジーを使用して、多くのコードと実際にはほぼすべてのコードを記述することができます。インラインガジェットを実装すると、Javascript Ninjaをより多く練習できるようになります。
では、決定アルゴリズムは何ですか？ウィジェットの作成者：ウィジェットをiframeとして実装できる場合は、ユーザーのセキュリティと信頼を維持するためだけにiframeを使用してください。ウィジェットでインライン化が必要な場合（およびメディアで許可されている場合、たとえばiGoogleや友人ではない）、インラインを使用しますが、ユーザーの信頼を悪用しないでください
ウィジェットインストーラー：ブログにウィジェットをインストールするとき、ウィジェットに「ユーザーにとって安全」なリボンが表示されません。ウィジェットが安全かどうかをどのように確認できますか？私が提案できる選択肢は2つあります。1）ベンダーを信頼する2）コードを読む。とにかくウィジェットプロバイダーを信頼してインストールするか、時間をかけてそのコードを読んで、信頼できるかどうかを判断してください。現実には、ほとんどのサイト所有者はコードを読むことを気にせず、ユーザーを危険にさらすことさえ知らないため、ウィジェットプロバイダーは盲目的に信頼されています。多くの場合、ブログは読者に関する個人情報を保持しないため、これは問題ではありません。知名度の高いエクスプロイトがほとんどなくなると、状況は変化し始めると思います（そして、それが決して実現しないことを願っています）。
ユーザー：Usresは暗闇の中で保管されています。ウィジェットのサイト所有者がインストールするウィジェットに「ユーザーにとって安全」なリボンがないように、「安全に使用できる」サイトはなく、基本的にユーザーは技術的なスキルを持っているかどうかにかかわらず、暗闇に置かれ、見当がつかない使用しているサイトにはウィジェットが含まれています。ウィジェットがインラインであるかどうか、およびそれらが悪意があるかどうかです。理論的には、訓練された開発者はブラウザで実行してハッカーにメールアカウントを紛失する前に、コードを事前に検査できますが、これは実用的ではなく、ユーザー全体がそれを行うことは期待できません。 IMOこれは不幸な状況であり、攻撃者がそれを利用する方法を見つけられないことを望み、Webでのすばらしいオープンウィジェット文化を運命づけます。
幸せなウィジェットの人々！
- 一部のブログプラットフォームは、ウィジェットの構造が多少異なり、ウィジェットとプラグインの両方が機能に関連している場合がありますが、ここでの議論に関しては、ウィジェットという用語を使用して「生」タイプを説明します。クライアント側のjavascriptコードで構成されます**ほとんどの場合、ウィジェットにホスティングページからスタイルを継承させ、見た目と一貫性を持たせたいのですが、実際にはウィジェットがページからスタイルを継承したくない場合があります。この場合、iFrameを使用すると、CSSをゼロから開始できます。
両方をしないのはなぜですか？
サードパーティのサイトに次のようなスクリプトを提供することを好みます。
<script type="text/javascript" src="urlToYourScript"></script>
サーバー上のファイルは次のようになります。
document.writeln('<iframe src="pathToYourWidget"
name="MagicIframe" width="300" height="600" align="left" scrolling="no"
marginheight="0" marginwidth="0" frameborder="0"></iframe>');
更新：
サーバー上のURLを指すiframeを使用する場合の欠点の1つは、誰かがサーバーからサーバーを指すURLをクリックしても「実際の」バックリンクが生成されないことです。
多くの開発者/サイト所有者は、iframeを使用するのではなく、ニーズに合わせてスタイル設定できるJavascriptソリューションを高く評価するでしょう。サードパーティ製のコンポーネントを含める場合は、Javascriptを使用する方がより適切に制御できるためです。
使いやすさに関しては、どちらもシンプルさが似ているため、実際のトレードオフはありません。
別の考えとして、これをホストしているドメインのSSL証明書を取得し、ページがSSL経由で提供される場合は、それに応じてincludeステートメントを書き出すようにしてください。サイト所有者がSSLを使用する理由がある場合、Firefoxや他のブラウザは、ページにセキュア/セキュアでないコンテンツが混在して提供されると文句を言うので、きっと感謝します。
ウィジェットをiframeに埋め込むことができる場合、iframeはコンテンツのダウンロードをブロックしないため、ホスティングサイトのフロントエンドのパフォーマンスが向上します。ただし、他の人がコメントしているように、iframeの使用には他の欠点もあります。
JavaScriptで実装する場合は、開発時に フロントエンドパフォーマンスのベストプラクティス を考慮してください。特に、 非JavaScriptローディング を確認する必要があります。 Googleアナリティクスおよびその他のサードパーティウィジェットプロバイダーは、この読み込み方法をサポートしています。ページの下部にjavascriptをロードできる場合にも役立ちます。
ソーシャルネットワーキングサイトに展開するのではなく、単にWebの残りの部分を残すだけであることを知ってうれしいです;-)
最も有用なものは、ウィジェットによって異なります。 IFrameとjavascriptは一般にまったく異なる目的に使用され、混在させることができます（iframe内のjavascript、またはiframeを作成するjavascript）。
- IFrameにはサイズの問題があります。ページに完全にフィットするはずの場合、すべてのブラウザで同じようにレンダリングされること、データがコンテナなどでオーバーフローしないことを知っていますか？
- IFrameは単純です。シンプルで静的なHTMLページにすることができます。
- IFrameを使用する場合、ウィジェットを非常にわかりやすく公開します。
- しかし、再び、サードパーティのサイトに特定のURLにHMTLを含めるだけではどうですか？その後、必要に応じてHTMLを拡張してjavascriptを含めることができます。
- Pure Javascriptを使用すると柔軟性が高まりますが、多少の複雑さが伴います。
Iframeの大きなプラス：すべてのCSSとJSはホストページから分離されているため、既存のCSSはそのまま機能します。 （ホストサイトでコンテンツのスタイルを合わせたい場合は、もちろんマイナスです。）
Iframeの大きなマイナス：幅と高さが固定されており、コンテンツが大きくなるとスクロールバーが表示されます。