現時点では、フレーム セットのある予約 Web サイトを使用しています。
たとえば、40% が独自の Web サイトからのものであるため、フレームのないサイトに簡単に変更できます。
ただし、実際の予約フローは別の Web サイト (これも当社が管理) からのものであり、独自に「ライブ」することを意図しているため、サードパーティの Web サイトも予約フローを購入/使用できます。
上司はフレームを少なくしたいと考えていますが、予約フローを適切に埋め込むことに問題があると考えています。これにはまったく触れたくないからです。
それに対処する最善の方法は何ですか？
もちろん、時間とお金の問題もありますが、今はそれを当然のことと考えています。
別のサイトを扱っている場合、最も簡単な方法は IFrame を使用することです。
その欠点は、その高さをその中のコンテンツと同じに設定するのが難しい場合があることですが、それを回避できれば問題ありません。
参考までに、かなり人気のある購入サイトのポップアップ購入プロセス (heh PPP) を IFrame に変換することに成功しました :P
さらに 2 つの提案:
多くの iframe の使用で見られる問題は、レンダリングする必要があるコンテンツのサイズを知ることです。iframe はコンテンツに合わせてサイズ変更されません。固定の幅と高さを指定する必要があります。
最近、フレームの使用がタブーになっていることは承知していますが、この Web サイトでは、フレームを使用しても問題はありませんか? それはあなたに本当の問題を引き起こしますか？
予約ウェブサイトはそのままにしておくべきなので、フレームに固執するか、iframe を使用します。
サーバー側または ajax リクエストを使用してから html を解析すると、問題が発生します。予約サイトのインターフェースが少しでも変わったら？
Web サービスを使用して予約 Web サイトを拡張することを考えたことはありますか?
2 つのサイトが異なるドメインまたはプロトコル (予約は https である可能性が高いようです) に存在する場合、シンプルな AJAX ソリューションが出てきます。
HTML 出力を変更すると大量のバグが発生し、戻るにはプロキシが必要になります。
iframe は必要なことを行いますが、x ドメインの問題により、フローを再びメイン ページに戻すのに問題が生じる可能性があります。
すべてのことを考慮すると、通常、セカンダリ予約サービスはサービスであると予想され、サーバー側でそれと対話します。現実的には何らかの方法で API が必要です。Web サービスは、私が想像する最もクリーンな方法になるでしょう。