🔆 👩🏻‍🎓 👨🏾‍🏭 自転車：マッシュアップアプリケーション開発ツールとしてのjQuery.ajaxに代わるiframe。理にかなっていますか？ 🆎 🔕 🧜🏻

みなさんこんにちは！コミュニティの注目を集めて、あまり労力をかけずにajaxで実行するiframeのようなアプリケーションを作成できる技術的なメカニズムを提供したいと思います。基礎としてjQueryとeasyXDMを使用しました。

技術的な説明、プロトタイプ、考えられる使用法に関する想定、およびカットの下での疑問。

まず、 マッシュアップの記事では、一般的な概念を意味するものではなく、

しかし、特定の特別なケースです。必要に応じて、単一ドメインWebアプリケーション

（ サービス ）-別の（ プラットフォーム ）に埋め込みます。

ユーザーはサイトページにいて、 サービスと対話できます。

既存のソリューションの欠点

iframe

iframe内で移動しても、ブラウザ行のURLは変わりません。
iframeの高さがコンテンツに応じて自動的に変更されるように、さらに何かを行う必要があります。
セッションでのユーザーの現在の位置を保存する必要があります。F5をクリックすると、サービスのメインページではなく、ユーザーが表示された最後のページが表示されます。
外部サイトへのリンクがtarget = "_ parent"またはtarget = "_ blank"で開いていることを確認する必要があります。そうしないと、外部リソースもiframe内で開き、奇妙に見えます。
サイトの対応するページへの自動リダイレクトが存在するように、「新しいタブで開く」モードでのクリックのロジックを検討する必要があります。
ライトボックス内の画像などの大きなポップアップブロックを表示する場合、サイズ制限があります。
すべての検索エンジンがiframeコンテンツのインデックスを作成できるわけではありません。
一般的な承認を整理することの難しさ。

サービスサーバーの第3レベルドメイン

サービスの作成者が特定のサイトごとに開発を行う必要性（各特定のサイトの帽子、地下室、デザインを組み立てる）
サードレベルドメインを登録するためのサイト側の追加の努力。
サイトの開発に関連して地下室の上限を更新する必要性。
一般的な承認を整理することの難しさ。

提案されたソリューションにより、すでに実行中のアプリケーションからメッシュをすばやく編成したり、新しいアプリケーションを簡単に作成したりできます。

プロトタイプデモ

http://mashups.ru/demo

私はMacでそれをテストしませんでした:(

これは、サービス（さまざまなWebメカニズムを使用する通常のphpアプリケーション）およびサービスが構築されるさまざまなテストサイトです。サービスにはphpソースコードがあります。コメントには、メッシュとして機能するために必要なポイントがあります（これらについては記事の後半で説明し、コードではコメントで＃for_mashup＃とマークされます）。ホスティングは地球の反対側にあり（実際のHTTP遅延があります）、これにより、一部のブラウザーは、通常のWebアプリケーションと比べて速度がajaxの利点を肉眼で確認できます。これは、最初に開かれるページではなく、サービスリンクの後続のクリックを意味します。

技術的なポイント

サービスのサーバー部分。 すべてが機能するには、サービスアプリケーションのサーバー側に特別なコードを追加して、通常のサーバー応答をjsonp応答に置き換える必要があります。たとえば、GET要求に対するサービスの応答：

<div>hello world</div>

に置き換えられます

 callback_function( { "content": "<div>hello world<\/div>" } );

へのPOST応答

 <script>parent.callback_function( { "content": "<div>hello world<\/div>" } );</script>

これらの置換により、プラットフォームページにあるブラウザーからクロスドメインajaxリクエストをサービスサーバーに送信できます。同様に、301 HTTPサービス応答をシミュレートする場合の場所が送信されます。例：

 callback_function( { "location": "/postSuccess/" } );

PHP言語では、このような置換は、 ob_start関数を介して出力コールバックをハングさせることで簡単に実装できます。サービスの開発者に直接、すべてのページで実行されるスクリプトでは、このすべてを内部で実行する特別なスクリプトを追加するだけで十分です。

ブラウザでアプリケーションが動作するためには、 easyXDMのswfファイルを特定の場所に配置する必要があります<IE8。

また、特別なphpファイルserviceProviderを配置し、サービスに必要なjs、cssボディキット、およびセッションが機能することを決定します。

サイトのサーバー部分。 バナーシステムにコードを追加するように、JSコードをページに追加します。

クライアント部分。 easyXDMベースのJSライブラリがサービスページに追加され、以下を実行します。

HTMLサービスからのコードのAタグとFORMタグのhref属性とaction属性をそれぞれ置き換えます。
jQuery ajaxメソッド、DOMメソッドを置き換えます。
window.locationオブジェクトの類似物を作成します。
プラットフォームの対話環境を作成します。

window.locationアナログを除くすべては、メッシュおよびスタンドアロンWebアプリケーションで機能します。

window.locationは問題であるため、置き換えることはできません。したがって、サービスでwindow.locationを使用するには、MU.location（その類似物）に連絡する必要があります。これにより、マッシュアップ内での作業が保証されます。しかし、スタンドアロンアプリケーションおよびメッシュとしての操作性とサービスを確保することは非常に簡単です。

 ... <head> <script>var MU = window;</script> </head> ... <a href="#" onclick="MU.location.href = '/link/'; return false;"></a>

つまりグローバル変数MUをウィンドウとして定義します。メッシュのフレームワーク内で、特別なjsスクリプトがそれを目的のオブジェクトに置き換え、置換なしで通常のウィンドウのように機能します。

また、iframeタグのないバージョンを使用すると、ajaxおよびDOM jQueryメソッドにアクセスする際に問題が発生します。実際、ページには2つのバージョンのjQueryメソッドがあり、1つはプラットフォームのフレームワーク内で動作し、もう1つはサービスのフレームワーク内で動作します。

そのようなインターフェースソリューションがありますが：

 $.muDom();

その後、DOM jQueryメソッドの呼び出しは、サービス内で1回の呼び出しでのみ実行されます。

 $.muAjax ();

その後、ajax jQueryメソッドの呼び出しは、サービス内で1回の呼び出しでのみ実行されます。

例：

 $.muAjax(); $.get( '/page', function( response ) { alert(response ) } ); //   alert    http://[ ]/page;  , , $.get    . $.get( '/page', function( response ) { alert(response ) } ) //       http://[ ]/page;

サイトに統合されたサービスのhtml / cssデザインを編集するプロセスを簡素化するアイデアはありません。しかし、私の意見では、最も簡単な方法の1つは、id属性やclass属性を十分に備えたサービスで正しいセマンティックレイアウトを行うことです。そうすれば、後で簡単に理解できます。まあ、CSSは編集を意味します。この場合、レイアウト設計者の作業のみが必要であり、プログラマーの作業は実際には必要ありません。

iframeの有無にかかわらず統合できます。 iframeを使用するか使用しないバージョンを使用するかは、サービスによって異なります。 iframeはより安全であるため、サービスはプラットフォームjsメソッドを実行したり、document.cookieを読み取ったりすることはできません。それがなければ、より自由になりますが、誰かが自分のページに設定したいと思う可能性は低くなります。おそらく、信頼性に依存します。たとえば、多くの人がfacebookウィジェットをインストールしますが、誰も（facebook）がdocument.cookieに静かになり、個人データを収集し、それを何らかの方法で自分のロジックで使用することを望んでいるとは考えていません。 Facebookは有名で人気のあるサービスだからです。部分的に、プラットフォームは、安全でないjsコードを削除し、サーバー上のajaxリクエストをチェックし、重要なCookieのhttpOnly属性を設定することにより、iframeなしのバージョンのセキュリティ問題を解決できます。

マッシュアップの作成に役立つその他のツール

iframeアナログのみのプロトタイプがありますが、他の統合の問題を解決するための未実現のアイデアがまだあります。

一般認可

サイトでセクションマッシュアップを作成する場合、サイトの承認をサービスに転送する必要がある場合があります。同じサイトで2回目の登録をユーザーに依頼するのは、どうもそうではありません。各サービスの特別なセッションキーを通じて、特定の実装アイデアがあります。アイデアは、さまざまなサイトでoauthとその変更を研究するための追加の努力からサービス開発者を解放することです。また、サイトの開発者は、技術を選択し、サービスへの承認の転送を実装する時間を無駄にしています。

検索エンジンのサービスの可用性

必要に応じて、プラットフォームはサーバー側に特別なコードを追加できます。これにより、jsonはサービス応答を通過してリンクを置き換えます。検索エンジンのバージョンは、「＃」のないリンクで機能します。ただし、jsをサポートしているクライアントがそのようなリンクにヒットすると、「＃」が付いたページに自動的にリダイレクトされます。

ウィジェット

ユーザーをサイトの新しいセクションに移動するには、リンク付きのブロックを表示する機能が必要になる場合があります。たとえば、サイトのメインページでは、サービスの新しいページのウィジェットが役立ちます（最近の投稿、コメント、お知らせ、製品、イベントなど）。または、特定のページのコンテンツに基づいて、サービスセクションに最も近い意味のリンクを表示するウィジェット。ウィジェットのコンテンツは、サービスサーバーで生成されます。入力は、ページへのリンク、特定のコンテナのコンテンツ、一部の変数、キーワードなどです。

CPA統計

マッシュアップの有用性と、サービスの所有者とサイト間の相互決済を評価するには、CPA（アクションごとのコスト）統計ツールが必要になる場合があります。サービス開発者が主要なアクションを決定し、システムはユーザーによる実装に関する統計を収集します。

どのように使用できますか

外部サービスを使用してトラフィックを収益化し、機能を拡張する機能- 人気の高いサイトの統合を整理する時間を無駄にすることのないセクション。
開発リソースの節約により、特定の作業サイトのソーシャルネットワークに対するサービスアプリケーションの有用性/有用性を理解/検証します。
作業サイトのアプリケーションの開発と正常な起動後、最小限のコストで高いトラフィックで他のサイトに統合する機能。
人気のある地域サイトに関する特別なセクションの形で、 稼働中の連邦サイトのサービスを配布します。
既存のサイト用の追加のマーケティングツール（別のリソースにサービスを統合する機能）。
SEOと広告の時間とリソースを節約し、 スタートアップサービスのトラフィックがある既に機能しているWebサイトのフレームワークでアイデアを確認します。
スタートアップサービスがウェブサイトをまったく作成せず、すでに人気のあるツイストされていないサイトとの共同マッシュアップでお金を稼ぐ機会。
デザイナー（ucoz.ruなど）のサイトの場合、サービスをサイトに追加する機能-エンジンの一部として実装するのが難しいセクション。
高負荷サイトの場合、クライアント上の異なるサーバーによって生成されたコンテンツからページをキャッシュ、処理、およびアセンブルする機能により、負荷、HTTPトラフィック、ページ表示速度を削減する機能。
すでにfacebook.com、vk.com、odnoklassniki.ru、my.mail.ruにあるプラットフォームを組織するための補助ツールとしての大規模なサイトまたはソーシャルネットワーク 。外部企業向けのiframeアプリケーションを作成できます。
さまざまなサーバーから情報を収集する社内Webアプリケーション用。

主なアイデアは、トラフィックを引き付けることに成功したサイトに機会を提供し、それを収益化できるサイトと相互に有益に協力することです（トラフィック）。 Runetの調査（5ページ）によると、サービスモデルを使用して収益化されているサイトはわずか9.9％です。私の意見では、サイト間で簡単に相互に有益なサービスを交換できる可能性があると、この数字が上がり、最終的に新しいスタートアップサービスの開発を刺激できます。

疑い

わからないことはありますか、それとも間違っていると考え全体が役に立たなくなりますか？
iframeは誰にとっても優れたシンプルなもので、頻繁に使用されるのに、なぜ複雑なのですか？
たとえば、ソーシャルアプリケーションのURLは、iframeで許可されていないためではなく、単に誰も必要としないために変更されません。インターネットでは、私はほとんど不満を感じていませんでした。
問題の本質（そして、そこにあるのでしょうか？）iframeを使用していない人、または技術的に訓練されていない人に説明するのは非現実的です。
ソーシャルアプリケーションはすでに行われています-「1、2、そして完了です...通常のiframeがあります」、開発時間の節約はありますか？

この記事の助けを借りて、このプロジェクトがどれほど面白いかを知りたいと思います。誰もそれを必要としないことを理解するために、積極的な開発のための追加の動機を取得します。私は建設的な批判を喜んでいます。

自転車：マッシュアップアプリケーション開発ツールとしてのjQuery.ajaxに代わるiframe。 理にかなっていますか？