任何人都可以对Composite C1核心的内容进行高级描述吗？特别是我有兴趣知道插件架构如何工作以及系统的核心组件是什么,即当请求到达架构中发生的事情时.描述不必过于冗长,只需要一个步骤列表和所涉及的类.
希望核心开发团队之一能够启发我......并且可能会发布一些更多的API(请提示更多类文档).
Pau*_*erø 40
从请求到呈现的页面
请求采用的具体路径取决于您使用的C1的版本,因为它已在2.1.2版中更改为使用路由.让我们看看
Composite.Core.WebClient.Renderings.RequestInterceptorHttpModule将拦截所有传入的请求,并确定所请求的路径是否对应于有效的C1页面.如果是,则将URL重写为C1页面处理程序~/Rendererings/Page.aspx
2.1.1
Composite.Core.Routing.Routes.Register()将一个C1页面route(Composite.Core.Routing.Pages.C1PageRoute)添加到Routes-collection,查看传入路径,确定它是否是一个有效的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等,因此这对于它们正常工作并触发WebForms的事件生命周期是必要的.
而且,基本上就是这样.渲染所请求的页面非常简单且可扩展.例如,有一个扩展,使用MasterPages它可以非常优雅地简单地挂钩到这个渲染流程.而且因为我们正在使用它Routing来映射使用哪个处理程序,~/Rendering/Page.aspx所以MvcHandler如果你是一个Mvc狂热分子,它也可能会忘记并返回一个.
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对象传递的参数.还完全支持使用<f:function />元素调用带有Xml标记的函数,这意味着编辑,设计人员,模板制作者等可以轻松地访问丰富的功能,而无需知道如何编写.Net代码.
在这里阅读更多关于函数的信息http://users.composite.net/C1/Functions.aspx以及如何使用ie 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应用程序启动时由Composite C1核心调用.
数据事件
您可以使用静态方法订阅数据添加,编辑和删除事件(前置和后置)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等效类Composite.Core.IO.C1File和Composite.Core.IO.C1Directory.Net的文件和目录非常重要.这是由于可以在Azure上托管C1的性质,您可能无法以与在普通Windows Server上相同的方式访问文件系统.通过使用C1的文件和目录包装器,您可以确保您编写的代码也能够在Azure上运行.
C1控制台
控制台本身就是一个完整的主题,并且有许多API.
您可以使用Composite.C1Console.Trees.TreeFacade或Composite.C1Console.Elements.ElementFacade实现a 来创建自己的树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的一个基本部分是提供者,几乎所有东西都由提供者组成,甚至是核心功能的大部分.从透视图到树木以及元素和动作的控制台中的所有内容都被提供给C1.所有标准函数,数据层和用于函数调用编辑器的所有小部件都被提供给C1.与资源,用户和权限,url格式化程序等一起使用的所有本地化字符串都是提供者.
这里注册了可以响应DataFacade,Get,Update,Delete,Add等方法的所有提供者.每个提供程序都会通知系统它可以与哪些接口进行交互,C1确保将特定接口的所有请求路由到各自的数据提供程序.
在这里,我们定义了Console中的透视图和树.您在第一次启动控制台时看到的所有标准视角都在这里配置,不涉及魔术或黑盒子.
动作提供者能够基于其EntityToken向系统中的所有元素添加新的菜单项.当您想要为现有内容添加新功能(例如版本控制,外联网安全性,自定义剪切/粘贴以及列表继续)时,这非常强大.
LoginProvider是C1控制台用于验证用户身份并允许您登录的用户.不幸的是,这不是很开放,但有一些反思你应该全部设置.
Composite C1将使用所有已注册的FunctionProviders在系统启动时填充其内部函数列表.
WidgetProviders用于函数调用编辑器或表单标记等内容,以呈现用于选择数据的自定义UI.
在此处注册用于XSLT模板的自定义扩展
然后我们有几个部分用于纯配置,比如缓存或要并行化的内容,但它不像提供者那样有趣.
定义和使用部分
composite.config中的节和其他相关的.config文件是完全标准的.Net配置并遵守其规则.这意味着能够使用自定义元素,例如ie.Composite.Functions.Plugins.WidgetFunctionProviderConfiguration它必须被定义为一个部分.一个部分有一个名称,并引用一个可以继承的类型System.Configuration.ConfigurationSection.Composite使用Microsoft企业库来处理大多数常见的事情,例如配置和日志记录以及验证,因此所有Composites部分都继承自Microsoft.Practices.EnterpriseLibrary.Common.Configuration.SerializableConfigurationSection.现在,这种类型必须具有我们希望能够在.config文件中定义的所有元素的属性,并且.Net将自动确保为我们连接.
如果您想访问特定部分的配置,您可以调用Composite.Core.Configuration.ConfigurationServices.ConfigurationSource.GetSection(".. section name")并将其转换为您的特定类型,然后您可以继续使用.
为已定义的部分添加额外属性
通常.Net会在.config文件中编写元素或属性时会抱怨,这些元素或属性无法由负责该部分的类型或元素识别.这使得编写一个真正灵活的模块系统变得很困难,外部作者可以在其中向其提供者添加特定的配置选项,因此我们有了Assembler的概念.它是一个ConfigurationElement类,其中Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.AssemblerAttribute分配了一个属性,该类依次将Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.IAssembler接口作为参数,负责从.config文件中的元素获取这些自定义属性和值,并从中发出可用对象.这样.Net就不会抱怨无效的.config文件,因为我们注入了一个具有所有自定义属性属性的ConfigurationElement对象,我们可以通过IAssembler读取配置时获取它们
幻灯片
可以在这些lins上找到一些概述幻灯片
灵感和例子
GitHub上的C1Contrib项目是一个非常好的介绍如何与C1的不同部分进行交互.它是一系列小包装,可以原样使用,也可以用于灵感.有些包使用动态类型进行操作以启用接口继承.其他软件包在控制台中使用javascript api,而其他软件包则显示如何将函数提供程序,树和钩子命令用于现有元素.甚至还有一些如何使用客户端和服务器之间的Soap webservice通信进行操作的示例,这样您就可以按照自己的方式进行操作.而这样的例子不胜枚举.