c1-cms - Composite C1体系结构如何工作？

Question

任何人都可以对Composite C1内核中发生的事情进行高级描述吗？我特别想知道插件架构如何工作以及系统的核心组件是什么，即当请求到达时架构中发生了什么。该描述不必太冗长，只需列出步骤和所涉及的类即可。

希望其中一个核心开发团队能启发我...并可能发布更多API(请提示更多类文档)。

Answer 1

从请求到呈现页面

请求采用的具体路径取决于您使用的C1版本，因为在2.1.2版本中将其更改为使用“路由”。所以让我们看看

<2.1.2

Composite.Core.WebClient.Renderings.RequestInterceptorHttpModule将拦截所有传入的请求，并确定所请求的路径是否对应于有效的C1页面。如果确实如此，则该URL将被重写为C1页面处理程序~/Rendererings/Page.aspx

2.1.1

Composite.Core.Routing.Routes.Register()将C1页面路由(Composite.Core.Routing.Pages.C1PageRoute)添加到查看进入路径的Routes-collection中，以确定其是否为有效的C1页面。如果是，它将返回一个准备执行的~/Rendererings/Page.aspx实例。

好的，现在我们已经准备好一个IHttpHandler实例来构成要返回给客户端的页面。 IHttpHandler的实际代码很容易看到，因为它位于~/Renderers/Page.aspx.cs中。

OnPreInit

在这里，我们要确定请求的是哪种页面ID和哪种语言，并查看我们是否处于预览模式，哪种数据范围等。

OnInit

现在，我们从页面的每个内容占位符中获取内容，并执行其可能包含的功能。通过调用Composite.Core.WebClient.Renderings.Page.PageRenderer.Render并传递当前页面和占位符来完成。在内部它将调用ExecuteFunctions方法，该方法将遍历内容并递归解析C1函数元素(<f:function />)，执行它们并将元素替换为函数输出。这样做会一直到内容中不再包含功能元素，以防它们自己输出其他功能。

现在，所有内容都包装在Asp.Net WebForms控件中，并插入到我们的WebForms页面中。由于C1函数可以返回UserControl等WebForms控件，因此这对于它们正常工作并触发WebForms的事件生命周期是必不可少的。

而且，基本上就是这样。所请求页面的呈现非常简单且可扩展。例如，有一个扩展允许使用MasterPages，它可以非常优雅地插入此渲染流。并且由于我们使用Routing来映射要使用的处理程序，因此如果您是Mvc狂热者，也可以忘记~/Rendering/Page.aspx并只返回MvcHandler。

API

现在，当涉及到更多核心API时，取决于您要执行的操作有很多。但是您可以肯定，无论完成任务有什么必要的条件。

在最深处，我们拥有大多数其他API和立面都围绕的数据层。这意味着您可以使用原始数据执行大多数操作，而不必一直浏览外观。这是可能的，因为C1的大多数配置是通过使用其自己的数据层存储配置来完成的。

Composite C1核心小组尚未验证/重构和记录系统中的所有API，因此使用“公共(public)API”的概念进行操作，并且在有需求时可以成为API。后者是一个相当不错的稳定API，但没有保证。

公共(public)API文档位于http://api.composite.net/上在线

函数

函数是C1的基本组成部分，是一种从执行中抽象逻辑的技术。基本上，执行操作或返回一些数据/字符串/值的所有内容都可以作为函数的候选对象。最底层的功能是实现IFunction接口(interface)的.Net类，但是幸运的是，有许多更简单的方法可以使用它。 Out of the box C1支持定义为XSLT模板，C#方法或Sql的函数。也有社区支持使用Razor编写函数或将ASP.Net UserControls(.ascx文件)作为函数。

由于所有功能都在系统启动期间在C1中注册，因此我们使用Composite.Functions.FunctionFacade执行我们知道名称的任何功能。使用GetFunction获取对函数的引用，然后使用Execute执行该函数并获取返回值。函数可以采用在执行函数时作为真实.Net对象传递的参数。还完全支持使用<f:function />元素使用Xml标记调用函数，这意味着编辑器，设计人员，模板制作人员等可以轻松访问大量功能，而无需知道如何编写.Net代码。

在此处阅读有关http://users.composite.net/C1/Functions.aspx的函数的更多信息，以及在http://docs.composite.net/C1/ASP-NET/Razor-Functions.aspx处如何使用ie Razor 制作函数

全局化和本地化

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可帮助您做到这一点。

启动事件
如果您编写插件，则这些插件可以具有自定义工厂。 Web应用程序启动时，其他代码可以使用 ApplicationStartupAttribute 属性由Composite C1内核调用。

数据事件
您可以使用 Composite.Data.DataEvents<T> 上的静态方法订阅数据添加，编辑和删除事件(事前和事后)。要在系统启动时附加这些事件，请使用 ApplicationStartupAttribute 属性。

数据

如果您在相应的C1页面请求之外访问数据层，则Composite.Core.Threading.ThreadDataManager非常重要。这可能是一个自定义处理程序，只需将所有最新新闻作为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

在处理文件和目录时，重要的是要使用.Net的文件和目录的C1等效类Composite.Core.IO.C1File和Composite.Core.IO.C1Directory。这是由于C1可以托管在Azure上的性质，您可能无法以与普通Windows Server相同的方式访问文件系统。通过使用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步向导。 Workflows是使用Windows Workflow Foundation构建的，因此您对此很熟悉，应该感到宾至如归

在向控制台编写扩展程序时，还可以使用很多javascript外观和方法。远远超出我在这里所能涵盖的范围，因此即使在这里开始学习该主题，我也会避免自己。

Composite.config

C1的基本组成部分是提供程序，几乎所有内容都由提供程序组成，甚至很多核心功能也是如此。控制台中从“透 View ”到“树”的所有内容以及元素和操作均与提供程序一起馈入C1。与提供程序一起使用的所有标准函数，数据层和所有与Function Call编辑器一起使用的小部件都将被馈送到C1中。与资源，用户和权限，URL格式化程序等一起使用的所有本地化字符串都是提供程序。

Composite.Data.Plugins.DataProviderConfiguration

在此注册了所有可以响应DataFacade，Get，Update，Delete，Add等方法的提供程序。每个提供程序都会通知系统可以与之交互的接口(interface)，并且C1确保将对特定接口(interface)的所有请求路由到其各自的数据提供者。

Composite.C1Console.Elements.Plugins.ElementProviderConfiguration

在这里，我们定义了控制台中的透 View 和树。首次启动控制台时看到的所有标准透 View 均在此处进行配置，不涉及任何魔术或黑匣子。

Composite.C1Console.Elements.Plugins.ElementActionProviderConfiguration

Action 提供者能够基于其EntityToken向系统中的所有元素添加新的菜单项。当您想向现有内容添加新功能(例如版本控制，Extranet安全性，自定义剪切/粘贴)并且列表继续时，此功能非常强大。

Composite.C1Console.Security.Plugins.LoginProviderConfiguration

C1控制台将使用LoginProvider来验证用户身份，并让您登录或不登录。不幸的是，这不是很开放，但是经过一番思考，您应该已经准备就绪。

Composite.Functions.Plugins.FunctionProviderConfiguration

组合C1将在系统启动时使用所有已注册的FunctionProvider填充其内部功能列表。

Composite.Functions.Plugins.WidgetFunctionProviderConfiguration

WidgetProvider用于函数调用编辑器或窗体标记之类的东西，以呈现用于选择数据的自定义UI。

Composite.Functions.Plugins.XslExtensionsProviderConfiguration

XSLT模板中使用的自定义扩展已在此处注册

然后，我们有几个部分用于纯配置，例如缓存或要并行化的内容，但它不像提供程序那样有趣。

定义和使用节

Composite.config中的节以及其他相关的.config文件是完全标准的.Net配置，并遵守其规则。这意味着能够使用自定义元素，例如ie。 Composite.Functions.Plugins.WidgetFunctionProviderConfiguration它必须被定义为一个部分。节具有名称，并引用将从System.Configuration.ConfigurationSection继承的类型。 Composite使用Microsoft Enterprise Libraries处理大多数这些常见的事情，例如配置，日志记录和验证，因此所有Composites部分均继承自Microsoft.Practices.EnterpriseLibrary.Common.Configuration.SerializableConfigurationSection。现在，此类型只需要具有我们希望能够在.config文件中定义的所有元素的属性，并且.Net将自动确保为我们进行连接。

如果您要访问特定部分的配置，则可以调用Composite.Core.Configuration.ConfigurationServices.ConfigurationSource.GetSection(".. section name")并将其转换为您的特定类型和使用习惯。

向已定义的部分添加额外的属性

通常，如果您在.config文件中写入负责该部分或该元素的类型无法识别的元素或属性，.Net会抱怨。这使得很难编写一个真正灵活的模块系统，外部作者可以在其中为其提供程序添加特定的配置选项，因此我们有了汇编程序的概念。它是一个ConfigurationElement类，为其分配了Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.AssemblerAttribute属性，而该类又将Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.IAssembler接口(interface)作为参数，负责从.config文件中的元素获取这些自定义属性和值，并从中发出可用的对象。这样，.Net不会抱怨无效的.config文件，因为我们注入(inject)了一个具有所有自定义属性属性的ConfigurationElement对象，并且在通过IAssembler读取配置时可以掌握它们。

幻灯片

在这些lins上可以找到一些概述幻灯片

Overview

Extensibility points

Page request handling

Function system

Data system

Data type system

灵感和示例

GitHub上的C1Contrib项目很好地介绍了如何与C1的不同部分进行交互。它是一个小包装的集合，可以按原样使用或用于启发。有些包可以使用动态类型进行操作以启用接口(interface)继承。其他软件包使用控制台中的javascript api，而其他软件包则显示如何使函数提供程序，树和将命令挂钩到现有元素。甚至还有一些示例，说明如何使用客户端和服务器之间进行的Soap Web服务通信进行操作，以便您可以使其按自己的方式进行操作。而这样的例子不胜枚举。