リクエストからレンダリングされたページまで
リクエストがたどる具体的なパスは、バージョン2.1.2でルーティングを使用するように変更されたため、使用しているC1のバージョンによって異なります。だから見てみましょう
Composite.Core.WebClient.Renderings.RequestInterceptorHttpModule
すべての着信要求をインターセプトし、要求されたパスが有効なC1ページに対応しているかどうかを判断します。その場合、URLはC1ページハンドラーに書き換えられます~/Rendererings/Page.aspx
Composite.Core.Routing.Routes.Register()
Composite.Core.Routing.Pages.C1PageRoute
着信パスを調べるRoutes-collectionにC1ページルート()を追加し、それが有効なC1ページであるかどうかを判断します。~/Rendererings/Page.aspx
そうである場合は、実行の準備ができているインスタンスを返します。
IHttpHandler
これで、クライアントに返されるページを作成する準備ができたインスタンスができました。の実際のコードはにあるため、IHttpHandler
簡単に確認でき~/Renderers/Page.aspx.cs
ます。
ここでは、どのページIDとどの言語が要求されたかを把握し、プレビューモードであるかどうか、どのデータスコープなどを確認しています。
これで、ページの各コンテンツプレースホルダーからコンテンツを取得し、そこに含まれる可能性のある機能を実行します。Composite.Core.WebClient.Renderings.Page.PageRenderer.Render
これは、現在のページとプレースホルダーを渡すことによって行われます。内部的にはExecuteFunctions
、コンテンツを実行し、C1関数要素(<f:function />
)を再帰的に解決するメソッドを呼び出し、それらを実行して、要素を関数出力に置き換えます。これは、関数自体が他の関数を出力する場合に備えて、コンテンツに関数要素がなくなるまで実行されます。
これで、コンテンツ全体がAsp.Net WebFormsコントロールにラップされ、WebFormsページに挿入されます。C1関数はなどのWebFormsコントロールを返すことができるためUserControl
、これは、C1関数が正しく機能し、WebFormsのイベントライフサイクルをトリガーするために必要です。
そして、それは基本的にそれです。要求されたページのレンダリングは非常に単純で、非常に拡張可能です。たとえば、MasterPages
このレンダリングフローに非常にエレガントにフックするだけで使用できる拡張機能があります。また、Routing
使用するハンドラーをマップするために使用しているため、Mvc狂信者の場合は、忘れて~/Rendering/Page.aspx
aを返すこともできます。MvcHandler
API
さて、よりコアなAPIになると、何をしたいかに応じて、多くのAPIがあります。しかし、仕事を成し遂げるために必要なものが何であっても、あなたはかなり確信することができます。
最深部には、他のほとんどのAPIとファサードが中心となっているデータレイヤーがあります。これは、ファサードを常に通過するのではなく、生データを使用してほとんどのことを実行できることを意味します。これが可能なのは、C1のほとんどの構成が、構成を格納するための独自のデータレイヤーを使用して行われるためです。
Composite C1コアグループは、システム内のすべてのAPIをまだ検証/リファクタリングおよび文書化していないため、「パブリックAPI」の概念と、需要があればAPIになることができるもので動作します。後者はかなり安定したAPIですが、保証はありません。
公開APIドキュメントはhttp://api.composite.net/でオンラインになっています
関数
関数はC1の基本的な部分であり、実行からロジックを抽象化する手法です。基本的に、アクションを実行するか、データ/文字列/値を返すものはすべて、関数の候補になる可能性があります。最下位レベルでは、関数はIFunction
インターフェイスを実装する.Netクラスですが、幸いなことに、関数を操作する簡単な方法はたくさんあります。すぐに使用できるC1は、XSLTテンプレート、C#メソッド、またはSQLとして定義された関数をサポートします。Razorを使用して関数を記述したり、ASP.Net UserControls(.ascxファイル)を関数にするためのコミュニティサポートもあります。
システムの起動時にすべての関数がC1に登録されるため、を使用しComposite.Functions.FunctionFacade
て、名前がわかっている関数を実行します。を使用しGetFunction
て関数への参照を取得し、それExecute
を実行して戻り値を取得します。関数は、関数の実行時に実際の.Netオブジェクトとして渡されるパラメーターを受け取ることができます。要素を使用してXmlマークアップで関数を呼び出すことも完全にサポートされてい<f:function />
ます。つまり、エディター、デザイナー、テンプレートメーカーなどは、.Netコードの記述方法を知らなくても豊富な機能に簡単にアクセスできます。
関数の詳細については、http: //users.composite.net/C1/Functions.aspxを参照してください。また、Razorを使用して関数を作成する方法については、http://docs.composite.net/C1/ASP-NET/Razor-Functionsを参照してください。 aspx
グローバリゼーションとローカリゼーション
C1は、コアで完全な多言語サポートを備えています。Composite.Core.Localization.LocalizationFacade
システムにインストールされているロケールを管理するために使用されます。クエリ、追加、削除。ロケールはCultureInfo
、システムで認識されているオブジェクトであれば何でもかまいません。
Composite.Core.ResourceSystem.StringResourceSystemFacade
リクエストが実行されているCultureInfoと一致する文字列を実行時に取得するために使用されます。ページまたはテンプレートで文字列をハードコーディングする代わりに、これを使用してください。
ローカリゼーションについて詳しくは、http://docs.composite.net/C1/HTML/C1-Localization.aspxをご覧ください。
グローバルイベント
Composite.C1Console.Events.GlobalEventSystemFacade
土壇場で変更を加えることができるように、システムがシャットダウンしているときに追跡する必要があるかどうかを知ることが重要です。C1は高度にマルチスレッド化されているため、マルチスレッド化されたC1の拡張機能とモジュールを簡単に作成でき、マルチコアシステムと並列化を利用できるため、適切な方法でスレッドをシャットダウンすることも重要です。はあなたがそれをするのGlobalEventSystemFacade
を助けます。
スタートアップイベント
プラグインを作成する場合、これらにはカスタムファクトリを含めることができます。他のコードは、このApplicationStartupAttribute
属性を使用して、Webアプリの起動時にCompositeC1コアによって呼び出される可能性があります。
データイベント
の静的メソッドを使用して、データの追加、編集、および削除イベント(preおよびpost)をサブスクライブできますComposite.Data.DataEvents<T>
。システムの起動時にこれらのイベントにアタッチするには、ApplicationStartupAttribute
属性を使用します。
データ
Composite.Core.Threading.ThreadDataManager
対応するC1ページリクエストの外部でデータレイヤーにアクセスする場合は重要です。これは、すべての最新ニュースをRssフィードとしてフィードする必要があるカスタムハンドラーである場合もあれば、コンソールアプリケーションを作成している場合もあります。このような場合は、常にこのようにデータにアクセスするコードをラップすることを忘れないでください
using(Composite.Core.Threading.ThreadDataManager.EnsureInitialize())
{
// Code that works with C1 data layer goes here
}
データにアクセスして操作するには、DataFacadeクラスを使用しないことをお勧めしますが、このようなデータを取得、更新、削除、または追加するすべてのコードをラップします
using(var data = new DataConnection())
{
// Do things with data
}
IO
ファイルとディレクトリを操作するときは、C1と同等のクラスを使用し、.Netのファイルとディレクトリを使用することが重要Composite.Core.IO.C1File
ですComposite.Core.IO.C1Directory
。これは、C1をAzureでホストできるという性質によるもので、通常のWindowsServerと同じようにファイルシステムにアクセスできない場合があります。C1のファイルラッパーとディレクトリラッパーを使用することで、作成したコードをAzureでも実行できるようになります。
C1コンソール
コンソールはそれ自体が主題であり、多くのAPIがあります。
Composite.C1Console.Trees.TreeFacade
を使用して、またはComposite.C1Console.Elements.ElementFacade
を実装して、独自のツリーを作成できますComposite.C1Console.Elements.Plugins.ElementProvider.IElementProvider
。
を使用しComposite.C1Console.Events.ConsoleMessageQueueFacade
て、サーバーからクライアントにメッセージを送信し、メッセージボックスを開く、ツリーを更新する、特定の要素にフォーカスを設定する、新しいタブを開くなどの操作を行うことができます。
Composite.C1Console.Workflow.WorkflowFacade
特定のワークフローのインスタンスを取得し、それらと対話するために使用されます。Workflows
これはC1の非常に基本的な部分であり、マルチステップ操作を定義および実行する方法です。これにより、動作状態を保存することができます。サーバーが再起動したり、その他の予期しないことが発生した場合でも、10ステップのウィザードが持続します。はWindowsWorkflowFoundationWorkflows
を使用して構築されているため、これに精通しているので、自宅にいるように感じるはずです。
コンソールに拡張機能を作成するときにフックできるJavaScriptファサードとメソッドも豊富にあります。私がここでカバーすることができたよりはるかに多くなので、私はここでその主題について始めることさえ控えます。
Composite.config
C1の基本的な部分はプロバイダーであり、ほとんどすべてがプロバイダーで構成されており、コア機能の多くも含まれています。パースペクティブからツリー、要素、アクションに至るまで、コンソール内のすべてがプロバイダーとともにC1にフィードされます。関数呼び出しエディターで使用するすべての標準関数、データレイヤー、およびすべてのウィジェットは、プロバイダーとともにC1にフィードされます。リソース、ユーザーと権限、URLフォーマッターなどで使用するすべてのローカリゼーション文字列はすべてプロバイダーです。
- Composite.Data.Plugins.DataProviderConfiguration
ここでは、DataFacade、Get、Update、Delete、Addなどのメソッドに応答できるすべてのプロバイダーが登録されています。すべてのプロバイダーは、システムが対話できるインターフェースをシステムに通知し、C1は、特定のインターフェースに対するすべての要求をそれぞれのデータプロバイダーにルーティングするようにします。
- Composite.C1Console.Elements.Plugins.ElementProviderConfiguration
ここでは、コンソール内のパースペクティブとツリーを定義しています。コンソールを初めて起動したときに表示されるすべての標準パースペクティブがここで構成され、魔法やブラックボックスは含まれません。
- Composite.C1Console.Elements.Plugins.ElementActionProviderConfiguration
アクションプロバイダーは、EntityTokenに基づいて、システム内のすべての要素に新しいメニュー項目を追加できます。これは、バージョン管理、エクストラネットセキュリティ、カスタムカット/ペーストなどの既存のコンテンツに新しい機能を追加したい場合に非常に強力であり、リストは続きます。
- Composite.C1Console.Security.Plugins.LoginProviderConfiguration
LoginProviderは、C1コンソールがユーザーを認証し、ログインできるようにするために使用するものです。残念ながら、これはあまりオープンではありませんが、ある程度の反省があれば、すべて設定する必要があります。
- Composite.Functions.Plugins.FunctionProviderConfiguration
Composite C1は、登録されているすべてのFunctionProviderを使用して、システムの起動時に関数の内部リストを作成します。
- Composite.Functions.Plugins.WidgetFunctionProviderConfiguration
WidgetProvidersは、関数呼び出しエディターやフォームマークアップなどで使用され、データを選択するためのカスタムUIをレンダリングします。
- Composite.Functions.Plugins.XslExtensionsProviderConfiguration
XSLTテンプレートで使用するカスタム拡張機能はここに登録されています
そして、キャッシングや何を並列化するかなど、純粋な構成のためのいくつかのセクションがありますが、プロバイダーほど興味深いものではありません。
セクションの定義と使用
Composite.configおよびその他の関連する.configファイルのセクションは、完全に標準の.Net構成であり、その規則に従います。つまり、ieのようなカスタム要素を使用できるようになるということです。Composite.Functions.Plugins.WidgetFunctionProviderConfiguration
セクションとして定義する必要があります。セクションには名前があり、から継承するタイプを参照しSystem.Configuration.ConfigurationSection
ます。Compositeは、Microsoft Enterprise Librariesを使用して、構成、ロギング、検証などのこれらの一般的な処理のほとんどを処理します。そのため、すべてのCompositeセクションはから継承しMicrosoft.Practices.EnterpriseLibrary.Common.Configuration.SerializableConfigurationSection
ます。さて、このタイプは、.config-fileで定義できるようにしたいすべての要素のプロパティを持っている必要があり、.Netは自動的に物事を接続します。
特定のセクションの構成にアクセスしたい場合は、それを呼び出しComposite.Core.Configuration.ConfigurationServices.ConfigurationSource.GetSection(".. section name")
て特定のタイプにキャストします。
定義済みのセクションにプロパティを追加する
通常、セクションまたは要素を担当するタイプによって認識されない要素または属性を.configファイルに書き込むと、.Netは文句を言います。これにより、外部の作成者がプロバイダーに特定の構成オプションを追加できる、真に柔軟なモジュールシステムを作成することが困難になります。そのため、アセンブラーの概念があります。Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.AssemblerAttribute
属性が割り当てられたConfigurationElementクラスは、次のようになります。Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.IAssembler
.configファイルの要素からこれらのカスタム属性と値を取得し、そこから使用可能なオブジェクトを発行する引数としてのインターフェイス。このように、すべてのカスタム属性のプロパティを持つConfigurationElementオブジェクトを挿入し、IAssemblerを介して構成を読み取るときにそれらを取得できるため、.Netは無効な.configファイルについて文句を言いません。
スライド
いくつかの概要スライドはこれらのlinsにあります
インスピレーションと例
GitHubのC1Contribプロジェクトは、C1のさまざまな部分と対話する方法の非常に優れた入門書です。そのまま、またはインスピレーションを得るために使用できる小さなパッケージのコレクションです。インターフェイスの継承を有効にするために動的型で操作するパッケージがあります。他のパッケージはコンソールでjavascriptapiを使用しますが、他のパッケージは関数プロバイダー、ツリー、および既存の要素へのフックコマンドを作成する方法を示します。クライアントとサーバー間で行われているSoapWebサービス通信を操作して、希望どおりに動作させる方法の例もあります。そして、リストは続きます。