wordpress多站点配置教程怎么申请一个网站

当前位置： 首页 > news >正文

wordpress多站点配置教程,怎么申请一个网站,海淘返利网站怎么做,免费做四年级题的网站低代码平台的可视化设计器本质上是DSL#xff08;Domain Specific Language#xff09;的结构化编辑器。可视化设计器将编辑的结果序列化成文本格式时所采用的规范就是一种DSL语法定义。 Nop平台基于可逆计算原理#xff0c;提出了一整套系统化的构建机制来简化DSL的设计和…低代码平台的可视化设计器本质上是DSLDomain Specific Language的结构化编辑器。可视化设计器将编辑的结果序列化成文本格式时所采用的规范就是一种DSL语法定义。 Nop平台基于可逆计算原理提出了一整套系统化的构建机制来简化DSL的设计和实现使得我们很容易增加针对自己业务领域的DSL也很容易在已有DSL的基础上进行扩展。具体来说Nop平台中所定义的DSL一般采用XML语法格式符合所谓的XDSL规范要求。XDSL的设计要点如下: 一. DSL优先而不是可视化设计优先 很多低代码平台的设计重心是可视化设计器的简便易用导致它的DSL格式设计随意、混乱冗长不适合程序员人工阅读编写。XDSL强调DSL文本形式的设计应该简洁、直观可以手工编写也方便程序自动处理。可视化设计可以看作是文本形式DSL的另外一种形式的表象可视化表象和文本形式之间可以按照规范化的规则进行可逆转换。 在这种设计思想下同一个DSL可以具有多种可视化设计器比如NopORM模型对应的DSL是app.orm.xml这种模型文件而它的可视化设计器可以是Excel、PowerDesigner或者PDMiner。我们还可以增加更多的可视化设计器只要它们的设计文件可以和orm.xml模型文件实现双向转换。 在具体的业务应用中我们还可以增加采用定制化的可视化设计器比如一个局部的细节设计器只负责设计模型文件的某个部分然后通过差量合并运算将局部设计结果合并到整体模型中。 二. DSL的语法通过元模型来定义而所有的DSL共享同样的元模型定义语言。 DSL的价值在于它所抽象出来的具有业务价值的领域语义空间至于它采用什么样的语法形式本质上是一个次要问题。XDSL统一采用XML语法形式这样就可以引入统一的XDefinition元模型语言来规范具体的DSL语法。 元模型是描述模型的模型。类似于元数据是描述数据的数据。 orm x:schema/nop/schema/orm/orm.xdef xmlns:x/nop/schema/xdsl.xdef… /orm 在模型文件的根节点上我们通过x:schema来指定元模型定义文件。 orm.xdef这个元模型使用xdef.xdef这个元元模型来定义。 xdef.xdef采用xdef.xdef自身来定义所以我们不需要更高层次的元元元模型。
统一的元模型语言促进DSL之间的无缝嵌套 在Nop平台中大量的DSL元模型定义中会引用已经定义的其他DSL模型。例如 api.xdef和xmeta.xdef都会引用已定义的schema.xdef 不同的DSL使用同样的类型定义也便于复用同样的可视化设计组件、转换工具、校验规则等。 根据元模型自动提供IDE插件 Nop平台提供了一个IDEA插件nop-idea-plugin。它会根据x:schema指定的元模型自动校验DSL语法并实现自动语法提示链接跳转等功能对于函数类型的DSL节点它还可以提供断点调试功能。当我们增加一个新的DSL语言的时候不需要单独为它开发IDEA插件工具直接就可以得到IDEA开发支持。 根据元模型我们还可以自动推导得到可视化设计器。而不需要为每个DSL单独引入可视化设计器。 三. 所有DSL都需要提供分解、合并机制 一个DSL文件复杂到一定程度必然需要引入分解、合并、库抽象等管理复杂性的机制。XDSL定义了一组标准化的Delta差量语法具体参见xdsl.xdef meta x:extends_NopAuthUser.xmeta x:schema/nop/schema/xmeta.xdef xmlns:x/nop/schema/xdsl.xdef x:post-extendsbiz-gen:GenDictLabelFields xpl:lib/nop/core/xlib/biz-gen.xlib//x:post-extends /metax:extends用于继承已有的模型文件而x:gen-extends和x:post-extends是内置的元编程机制(Meta Programming)它们用于实现可逆计算理论中的Generator部分动态生成DSL模型对象然后再进行Delta合并。 x:override用于指定合并节点时所采用的合并策略具体定义参见可逆计算理论中的Delta合并算法 四. 通过差量文件系统管理所有DSL文件 Nop平台将所有的模型文件纳入统一的虚拟文件系统来管理。这个虚拟文件系统提供了类似Docker技术中UnionFS文件系统的功能内部不同的目录构成不同的层高层目录中的文件会自动覆盖低层目录中的相同虚拟路径下的文件。 具体来说/_vfs/_delta/default/a.xml会自动覆盖/_vfs/a.xml文件。在代码中所有使用虚拟文件路径/a.xml的地方在运行时实际加载的文件是/_vfs/_delta/default/a.xml文件。也就是说我们不用修改原有的源代码只需要在delta目录下增加同名的文件就可以自动改变实际加载的模型内容。 可以通过配置项 nop.core.vfs.delta-layer-ids来指定多个delta层缺省情况下只有一个default差量层。在delta目录下的XDSL文件可以通过 x:extendssuper来表示继承前一个层中的模型文件。可以将数据库表中保存的模型文件也映射到某个虚拟文件路径比如wf:MyWf/1.0表示从数据库中的NopWfDefinition表中加载模型文件。 借助于差量文件系统以及XDSL内置的Delta合并算法我们可以实现系统级别的Delta定制机制在完全不修改基础产品源代码的情况下通过增加Delta模块实现对系统的数据模型、业务逻辑、前端界面等进行深度的定制调整参见如何在不修改基础产品源码的情况下实现定制化开发 五. 通过统一的Loader来加载DSL模型 Nop平台中使用统一的ResourceComponentManager来加载所有的DSL模型。 OrmModel model (OrmModel)ResourceComponentManager.instance().loadComponentModel(/nop/auth/orm/app.orm.xml);当我们增加一种新的DSL模型的时候可以增加一个注册文件例如orm.register-model.xml model x:schema/nop/schema/register-model.xdef xmlns:x/nop/schema/xdsl.xdefnameormloadersxlsx-loader fileTypeorm.xlsx impPath/nop/orm/imp/orm.imp.xml/xdsl-loader fileTypeorm.xml schemaPath/nop/schema/orm/orm.xdef//loaders /model通过这个注册模型我们可以指定对于给定的文件类型如何进行解析得到模型对象。 xlsx-loader指定如何根据Excel导入模型配置解析Excel模型文件xdsl-loader指定DSL文件所必须具有的元模型并按照元模型进行解析模型文件的x:schema指定的元模型必须是schemaPath指定的值或者是在它基础上进行扩展的 基于统一的模型加载器我们可以实现针对任意模型的代码生成工具 java -jar nop-cli.jar gen abc.model.xlsx -t/nop/templats/my-modelgen命令接受一个模型文件参数然后通过-t参数来指定代码生成模板路径就可以自动解析模型文件得到模型对象传入到模板文件中生成代码。具体参见 数据驱动的差量化代码生成器 解析缓存和依赖追踪 ResourceComponentManager内部管理了所有DSL模型的解析缓存以及DSL模型文件之间的依赖关系。它的依赖追踪机制类似于前端Vue框架使用的依赖追踪即动态记录模型解析过程中加载或者使用过的DSL模型当模型文件的修改时间发生变化的时候所有依赖它的模型缓存都自动被记为失效。 nop-cli工具还提供了watch功能可以监听指定目录下为模型文件当模型文件发生变化的时候自动重新执行代码生成器生成衍生的代码。 可逆计算的切入途径 可逆计算原理的核心实现全部被封装在ResourceComponentManager这个抽象之中。在第三方应用中引入可逆计算最简单的方式就是把自己的模型加载函数替换为ResourceComponentManager.loadComponentModel。比如说为了给Spring和MyBatis框架引入模型文件的Delta定制功能我们重新实现了beans.xml和mapper.xml的扫描功能使用ResourceComponentManager来动态生成DOM对象然后调用Spring和MyBatis的解析器去解析并注册到对应引擎中。 理论层面的分析可以参见从张量积看低代码平台的设计 六. 所有的DSL模型对象都支持扩展属性 XDSL模型对象的属性并不是在开发期固化的它一般从AbstractComponentModel基类继承支持增加任意的扩展属性。在具体的业务应用中我们可以选择从已有的元模型继承增加业务特定的扩展属性。 比如平台中内置了xmeta.xdef这个元模型。 我们可以定义xmeta-ext.xdef元模型它从xmeta.xdef继承然后增加一些扩展字段 meta x:extends/nop/schema/xmeta.xdef xmlns:uiui xmlns:graphqlgraphqlx:schema/nop/schema/xdef.xdefxmlns:x/nop/schema/xdsl.xdef xmlns:xdef/nop/schema/xdef.xdefpropsprop ui:showstring graphql:typestring //props/meta以上元模型表示为xmeta模型的prop节点增加ui:show属性和graphql:type属性。 然后在具体的meta文件中我们就可以使用xmeta-ext.xdef来替换原有的xmeta.xdef。 meta x:schema/my/schema/xmeta-ext.xdef…/metaIDEA插件会自动识别并使用扩展的元模型定义来校验Meta文件。使用ResourceComponentManager.loadComponentModel加载的模型对象上会包含扩展属性。 也就是说在不修改平台内置元模型定义的情况下我们可以随时为已有的模型对象增加扩展属性并在编程中像内置属性那样使用它们。 基于可逆计算理论设计的低代码平台NopPlatform已开源 gitee: canonical-entropy/nop-entropygithub: entropy-cloud/nop-entropy开发示例docs/tutorial/tutorial.md可逆计算原理和Nop平台介绍及答疑_哔哩哔哩_bilibili