0

このアプリでは、クロス ドメイン リクエストを作成しているため、CORS を使用する必要があります。$httpIE はこれを非標準的な方法で行うため、これらすべてを処理する独自のサービス (IE 以外の要求に対して依存関係がある) を作成しました。これはすべて、このアプリ内で正常に機能します。ただし、リクエストを行う必要がある、アプリ固有ではないライブラリ コードがいくつかあります。そのため、ライブラリ コードでこれらのサービスが単純に を使用する$httpと、CORS を実行する必要があるアプリでリクエストが機能しなくなります。ただし、これらのサービスが CORS サービスを挿入することは望ましくありません。これは、クロスドメイン リクエストを実行していないアプリでのリクエストが中断されるためです。

そうは言っても、私の最終的な目標は、ライブラリ コードを挿入して、$http必要なすべての要求に使用することです。次に、特定のアプリで、どのように機能するかを定義できます$http。最初は、プロバイダーを再定義するだけでよいと考えていました$http。このようなもの：

angular.module("myCorsApp").provider("$http", function() {
    return {
        $get: function(CORShttpService) {
            return CORShttpService;
        }
    }
});

ただし、これにより次のエラーが発生します。

Circular dependency: CORShttpService <- $http <- $compile

循環依存関係がどこから来ているのか理解できません。$compileプロバイダーなどに依存していますか?

私の本当の問題は、私がこれを正しい方法で行っているかどうかです。循環依存関係がなければ、これでまさに私が望んでいることを達成できると思います。これを機能させるためにできる回避策はありますか？これを行うためのより良い/より正しい方法はありますか?

それが役立つ場合CORShttpService、次の依存関係があります: $q、$rootScope、$http、$timeout。助けてくれてありがとう。

4

1 に答える 1

1

Angular のドキュメントをいろいろ調べた結果、ここでの最善のアプローチは$httpサービスを「装飾する」ことだと判断しました。これは、サービスのデコレータ機能$provideで行われます。だから、私はこのようなものになりました：

angular.module("myCorsApp").config(function($provide) {
    $provide.decorator("$http", ["$delegate", "$q", "$rootScope", "$timeout", function($http, $q, $rootScope, $timeout) {
        return function(requestConfig) {
            //CORS logic using $http (basically what was the CORShttpService)
        }
    }]);
});
于 2013-04-10T19:02:28.813 に答える