54

サードパーティのサイトで使用されるウィジェットを開発する必要があります。これは、ソーシャルネットワーキングサイトに展開されるアプリケーションではありません。サイトの人にiframeのsrcとして使用するリンクを与えるか、JavaScriptリクエストとして開発することができます。

2つのアプローチ（IFrameとJS）のトレードオフを教えてもらえますか？

4

6 に答える 6

31

私は同じ質問について検索していて、次の興味深い記事を見つけました:
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 "こんにちはウィジェットの世界"; } 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 ファイルがホストされている場所を気にしないことに注意してください。コードが同じフレームで実行されている限り、ブラウザはすべてのコードをフレームのドメインで発生したものと見なします。したがって、ユーザーとしてのあなたは、メール アカウントの制御を失うことで傷つき、my-wonderful-email は評判を失うことで傷つきます。

同じクロックが iframe 内に実装されていて、iframe ソースがページ ソースと異なる場合 (これはよくあるケースです。たとえば、ページ ソースが my-wonderful-email.com で、ガジェット ソースが great-clock-widgets の場合) .com) の場合、ブラウザは時計ウィジェットがページの Cookie にアクセスすることを許可せず、ホスト ページの DOM を含むホスティング ドキュメントの他の部分へのアクセスも許可しません。その方がずっと安全です。実際のところ、iGoogle などの個人のホームページではインライン ガジェットさえ許可されておらず、iframe ガジェットのみが許可されています。(インライン ガジェットは、悪意がないことを確認するために iGoogle チームによる徹底的な検査の後にのみ、まれなケースでのみ許可されます)

要約すると、iframe ウィジェットはより安全です。ただし、機能が大幅に制限されています。次に、失われる機能について説明します。

ルック アンド フィール ルック アンド フィール バトルでは、インライン ガジェット (通常**) が勝利します。それらの良いところは、ページの一部として表示できることです。フォント、色、テキスト サイズなどを含むページから CSS スタイルを継承できます。

しかし、さらに重要なことは、iframe がそのサイズがどうなるかを宣言しなければならないということです。ページに iframe を追加するときは、幅と高さのプロパティを含める必要があります。含めない場合、ブラウザはいくつかのデフォルト設定を使用します。ここで、あなたのウィジェットが簡単な時計ウィジェットである場合、どのサイズにするかは正確にわかっていますが、多くの場合、ウィジェットがどれだけのスペースを占有するかは事前にわかりません. たとえば、ある種のリストを表示するウィジェットを作成していて、このリストの長さや各項目の幅がわからない場合。通常、HTML ではこれは大したことではありません。なぜなら、HTML は宣言型言語であるため、何を表示したいかをブラウザに伝えるだけで、ブラウザは適切なレイアウトを見つけ出すからです。ただし、iframe の場合はそうではありません。ifrmaes では、ブラウザーは iframe のサイズを正確に伝えることを要求しますが、それ自体では判断できません。これは、iframe を使用したいウィジェット作成者にとっては深刻な問題です。必要なスペースが多すぎると、ページに空白ができてしまいます。また、指定したスペースが小さすぎると、ページにスクロールバーが表示されることになります。

見た目も気分も賢く、インラインが勝ちます。ただし、これは実際にはウィジェット アプリケーションに依存することに注意してください。やりたいことが時計だけなら、iframe も同様にうまくいくかもしれません。

サーバー側とクライアント側の IFrmaes では、src URL を指定する必要があるため、iframe を使用してウィジェットを実装する場合は、サーバー側のコードが必要です。これは、サーバー、ドメイン名などの所有、負荷の処理、ネットワーク料金の支払いなどの制限と頭痛の両方になる可能性がありますが、他の人にとっては、これは実際には iframe b/c を支持するポイントです。ウィジェットはサーバー サイド テクノロジに組み込まれているため、asp.net、django、ror、jsp、struts、perl、その他の恐竜など、好みのサーバー サイド テクノロジを使用して、多くのコードと実際にはほとんどすべてのコードを記述できます。インライン ガジェットを実装すると、JavaScript Ninja の練習がますます増えます。

決定アルゴリズムは何ですか？ウィジェット作成者: ウィジェットを iframe として実装できる場合は、単にユーザーのセキュリティと信頼を維持するために iframe を優先します。ウィジェットがインライン化を必要とする場合 (メディアがインライン化を許可している場合、たとえば iGoogle や友人を除く) はインラインを使用しますが、あえてユーザーの信頼を悪用しないでください。

ウィジェット インストーラー: ブログにウィジェットをインストールすると、ウィジェットに「ユーザーにとって安全」なリボンが表示されません。ウィジェットが安全かどうかはどうすればわかりますか? 私が提案できる代替案は 2 つあります。1) ベンダーを信頼する、2) コードを読む。ウィジェット プロバイダーを信頼してとにかくインストールするか、時間をかけてそのコードを読み、信頼できるかどうかを自分で判断します。現実には、ほとんどのサイト所有者はわざわざコードを読んだり、ユーザーを危険にさらしていることに気付いていないため、ウィジェット プロバイダーは盲目的に信頼されています。ブログは通常、読者の個人情報を保持していないため、多くの場合、これは問題になりません。目立ったエクスプロイトがほとんどなくなると、状況が変わり始めるのではないかと思います (そして、それが実現しないことを願っています)。

ユーザー: ユーザーは秘密裏に保管されます。ウィジェット サイトの所有者がインストールする「ユーザーにとって安全」なリボンがないのと同じように、「安全に使用できる」サイトもありません。基本的に、ユーザーは暗闇に置かれ、たとえ技術的なスキルを持っていても、わかりません。使用しているサイトにウィジェットが含まれているかどうか、ウィジェットがインラインかどうか、悪意があるかどうか。理論的には、訓練を受けた開発者は、コードをブラウザーで実行してメール アカウントをハッカーに奪われる前に、事前にコードを調べることができますが、これは実際的ではなく、ユーザーが大量にそれを行うことを期待するべきではありません。IMO これは不幸な状況であり、攻撃者がそれを利用する方法を見つけず、Web 上の素晴らしいオープン ウィジェット カルチャーを破滅させないことを願うばかりです。

幸せなウィジェットの人々！

  • 一部のブログ プラットフォームでは、ウィジェットの構造が多少異なり、ウィジェットとプラグインの両方が機能的に相関している場合もありますが、ここでの議論の問題として、ウィジェットという用語をお粗末に使用して、「生の」タイプについて説明します。クライアント側の JavaScript コードで構成されています ** ほとんどの場合、ウィジェットにホスティング ページからスタイルを継承させて、見た目に一貫性を持たせたいと思いますが、実際には、ウィジェットにページからスタイルを継承させたくない場合もあります。この場合、iFrame を使用すると、CSS を最初から作成できます。
于 2011-03-04T23:41:55.600 に答える
13

両方やってみませんか？

次のようなスクリプトをサードパーティのサイトに提供することを好みます。

 <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 をクリックした場合、「実際の」バックリンクを生成しないことです。

于 2012-12-15T19:09:52.623 に答える
5

多くの開発者/サイト所有者は、iframe. サード パーティのコンポーネントを含める場合は、より細かく制御できる Javascript を使用することをお勧めします。

使いやすさに関しては、どちらもシンプルさが似ているため、実質的なトレードオフはありません。

別の考えとして、これをホストしているドメインの SSL 証明書を取得し、ページが SSL 経由で提供される場合はそれに応じて include ステートメントを書き出すようにしてください。サイト所有者が SSL を使用する理由がある場合、Firefox やその他のブラウザーは、安全なコンテンツと安全でないコンテンツが混在するページが提供されると文句を言うため、これを歓迎するでしょう。

于 2011-03-04T23:59:25.130 に答える
3

ウィジェットを iframe に埋め込むことができる場合、iframe はコンテンツのダウンロードをブロックしないため、ホスティング サイトのフロントエンドのパフォーマンスが向上します。ただし、他の人がコメントしているように、iframe の使用には他の欠点があります。

JavaScript で実装する場合は、開発時にフロントエンド パフォーマンスのベスト プラクティスを考慮してください。特に、Non-blocking javascript loadingを確認する必要があります。Google アナリティクスおよびその他のサードパーティ ウィジェット プロバイダは、この読み込み方法をサポートしています。また、ページの下部にある JavaScript をロードできる場合にも役立ちます。

于 2011-03-15T22:54:13.057 に答える
2

それがソーシャルネットワーキングサイトに展開されるべきではないことを知ってうれしいです...それは単にウェブの残りの部分を残すだけです;-)

何が最も役立つかは、ウィジェットによって異なります。IFrameとjavascriptは一般にまったく異なる目的を果たし、混合することができます（つまり、iframe内のjavascript、またはiframeを作成するjavascript）。

  • IFrameにはサイズの問題があります。ページにぴったり合うと思われる場合は、すべてのブラウザで同じようにレンダリングされ、データがコンテナなどにオーバーフローしないことをご存知ですか？
  • IFrameはシンプルです。シンプルで静的なHTMLページにすることができます。
  • IFrameを使用すると、ウィジェットが非常にわかりやすく表示されます。
  • しかし、繰り返しになりますが、サードパーティのサイトに特定のURLにHMTLを含めてみませんか？HTMLは、必要なときに/必要に応じてjavascriptを含むように拡張できます。
  • 純粋なJavascriptを使用すると、柔軟性が向上しますが、多少の複雑さが伴います。
于 2009-02-11T06:59:31.070 に答える
1

iframe の大きな利点: すべての CSS と JS がホスト ページから分離されているため、既存の CSS が機能します。(ホスト サイトにコンテンツが収まるようにスタイルを設定してもらいたい場合は、もちろんマイナスです。)

iframe の大きな欠点: 幅と高さが固定されており、コンテンツが大きい場合はスクロール バーが表示されます。

于 2016-06-02T15:41:48.363 に答える