docs: synced via GitHub Actions

Author: nop-cao

src/arch/module-dependency.md

@@ -47,7 +47,7 @@ Nop平台的后端服务使用NopGraphQL引擎实现。NopGraphQL引擎没有使
 
 * nop-orm实现了一个包含Hibernate和MyBatis所有核心功能的ORM引擎
 
-* nop-biz中的[BizObjectManager](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-biz/src/main/java/io/nop/biz/impl/BizObjectManager.java)提供了[IGraphQLSchemaLoader](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-graphql/nop-graphql-core/src/main/java/io/nop/graphql/core/schema/IGraphQLSchemaLoader.java)接口的实现，将GraphQL调用映射到BizModel的方法上。这个过程类似于REST框架将URL链接映射到Controler类的方法上，具体参见[graphql-java.md](https://gitee.com/canonical-entropy/nop-entropy/blob/master/docs/dev-guide/graphql/graphql-java.md)。nop-biz模块内置了[CRUD服务](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-biz/src/main/java/io/nop/biz/crud/CrudBizModel.java)和[字典表服务](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-biz/src/main/java/io/nop/biz/dict/DictProviderBizModel.java)。
+* nop-biz中的[BizObjectManager](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-core-framework/nop-biz/src/main/java/io/nop/biz/impl/BizObjectManager.java)提供了[IGraphQLSchemaLoader](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-core-framework/nop-graphql/nop-graphql-core/src/main/java/io/nop/graphql/core/schema/IGraphQLSchemaLoader.java)接口的实现，将GraphQL调用映射到BizModel的方法上。这个过程类似于REST框架将URL链接映射到Controler类的方法上，具体参见[graphql-java.md](https://gitee.com/canonical-entropy/nop-entropy/blob/master/docs/dev-guide/graphql/graphql-java.md)。nop-biz模块内置了[CRUD服务](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-core-framework/nop-biz/src/main/java/io/nop/biz/crud/CrudBizModel.java)和[字典表服务](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-core-framework/nop-biz/src/main/java/io/nop/biz/dict/DictProviderBizModel.java)。
 
 * nop-biz通过nop-fsm内置了有限自动机机制，可以描述某些简单的业务流程
 
@@ -61,7 +61,7 @@ Nop平台在GraphQL引擎的基础上建立了分布式RPC机制，参见[rpc-de
 
 * nop-cluster-core提供了负载均衡、服务发现、Leader选举等集群相关的支持机制
 
-* nop-rpc-http将[IHttpClient](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-http/nop-http-api/src/main/java/io/nop/http/api/client/IHttpClient.java)接口封装成了IRpcService接口（RPC服务的内部实现接口）
+* nop-rpc-http将[IHttpClient](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-network/nop-http/nop-http-api/src/main/java/io/nop/http/api/client/IHttpClient.java)接口封装成了IRpcService接口（RPC服务的内部实现接口）
 
 * nop-rpc-cluster提供了广播式RPC调用和负载均衡RPC调用
 

src/compare/nop-vs-skyve.md

@@ -72,7 +72,7 @@ Skyve采用了XSD（XML Schema）语言来规范XML模型文件的格式，然
 
 ### 1. 同态设计
 
-XDef明确采用了同态映射的设计思想，XDef元模型的结构与模型自身的结构保持一致，只是在模型语法结构的基础上增加一些标注信息。例如[view.xdef](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-xdefs/src/main/resources/_vfs/nop/schema/xui/xview.xdef)
+XDef明确采用了同态映射的设计思想，XDef元模型的结构与模型自身的结构保持一致，只是在模型语法结构的基础上增加一些标注信息。例如[view.xdef](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-kernel/nop-xdefs/src/main/resources/_vfs/nop/schema/xui/xview.xdef)
 
 ```xml
 <!--
@@ -171,7 +171,7 @@ Nop平台提供了一个IDEA插件[nop-idea-plugin](https://gitee.com/canonical-
 </beans>
 ```
 
-以上例子是Nop平台和基于SpringBoot的若依Ruoyi框架集成时所定制的[dao-defaults.beans.xml](https://gitee.com/canonical-entropy/nop-for-ruoyi/blob/master/ruoyi-admin/src/main/resources/_vfs/_delta/default/nop/dao/beans/dao-defaults.beans.xml)。它删除了Nop平台缺省提供的数据源定义，为Ruoyi框架内置的dynamicDataSource设置了一个别名，从而使得Nop平台可以直接使用该数据源。
+以上例子是Nop平台和基于SpringBoot的若依Ruoyi框架集成时所定制的[dao-defaults.beans.xml](https://www.gitee.com/nop-entropy/null)。它删除了Nop平台缺省提供的数据源定义，为Ruoyi框架内置的dynamicDataSource设置了一个别名，从而使得Nop平台可以直接使用该数据源。
 
 ### 4. 元编程
 
@@ -189,7 +189,7 @@ Generator是可逆计算理论中的一个非常关键的部分。Nop平台的
 
 这种元编程机制非常强大，因为它类似于数学定理推导：只需要考虑如何符号变换得到最终需要的结果，完全不用考虑复杂的运行时状态依赖关系。
 
-在NopORM引擎中，JSON对象支持和扩展字段支持也是通过编译期运行技术实现的，ORM引擎本身并没有内置相关知识。具体参见[orm-gen.xlib](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-orm/src/main/resources/_vfs/nop/orm/xlib/orm-gen.xlib)
+在NopORM引擎中，JSON对象支持和扩展字段支持也是通过编译期运行技术实现的，ORM引擎本身并没有内置相关知识。具体参见[orm-gen.xlib](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-persistence/nop-orm/src/main/resources/_vfs/nop/orm/xlib/orm-gen.xlib)
 
 ### 5. 自定义扩展
 
@@ -207,7 +207,7 @@ Skyve中的模型对象属性是固定的，我们只能单方面接受Skyve的
 
 Skyve的做法是一种比较传统的做法，它针对每个模型单独实现具体功能。而Nop平台的做法是试图提供一个领域语言工作台(Language Workbench)，为开发领域特定语言提供一系列的技术支撑，从而使得我们可以根据领域需求快速的开发一个对应的领域特定语言。参见[XDSL：通用的领域特定语言设计](https://zhuanlan.zhihu.com/p/612512300)。领域语言工作台可以看作是一种面向语言编程(Language Oriented Programming)范式。IDEA的开发商JetBrains公司曾经发布了一个产品[MPS](https://www.jetbrains.com/mps/)专门用于实现LOP。Nop平台的设计目标和MPS大致上一致的，只是它是基于系统化的可逆计算理论，在基本的软件构造原理和技术路线方面与MPS有着本质性差异。
 
-在Nop平台中，所有的领域模型都是采用统一的元模型机制进行定义的，它们都符合基础的XDSL语法规范（XDSL语法规范由元模型[xdsl.xdef](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-xdefs/src/main/resources/_vfs/nop/schema/xdsl.xdef)定义）。借助于XDSL所提供的通用能力，我们自己定义的DSL可以自动获得差量合并、元编程、断点调试、可视化设计等能力。**例如对于工作流引擎，我们只需要编写最内核的流程运行时，无需额外工作即可得到可视化流程设计器、流程断点调试、差量定制、继承已有流程模板等能力**。
+在Nop平台中，所有的领域模型都是采用统一的元模型机制进行定义的，它们都符合基础的XDSL语法规范（XDSL语法规范由元模型[xdsl.xdef](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-kernel/nop-xdefs/src/main/resources/_vfs/nop/schema/xdsl.xdef)定义）。借助于XDSL所提供的通用能力，我们自己定义的DSL可以自动获得差量合并、元编程、断点调试、可视化设计等能力。**例如对于工作流引擎，我们只需要编写最内核的流程运行时，无需额外工作即可得到可视化流程设计器、流程断点调试、差量定制、继承已有流程模板等能力**。
 
 基于XDSL，我们还很自然的实现了多个DSL之间的无缝嵌入。比如在流程引擎中嵌入规则引擎，在规则引擎的动作中触发流程步骤等。
 

src/dev-guide/auth/auth.md

@@ -247,7 +247,7 @@ if (auth.getPermissions() != null && !auth.getPermissions().isEmpty()) {
 对于使用了复杂过滤条件的情况，会报错无法支持对应操作等异常，此时必须定义check。
 
 在`filter`段中可以编写权限过滤条件，其中`value`部分可以使用`@biz:`为前缀的表达式变量，例如`@biz:userId`、`@biz:deptId`等。
-全部可用的变量在[biz-var.dict.yaml](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-xlang/src/main/resources/_vfs/dict/core/biz-var.dict.yaml)
+全部可用的变量在[biz-var.dict.yaml](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-kernel/nop-xlang/src/main/resources/_vfs/dict/core/biz-var.dict.yaml)
 中定义。
 
 一般情况下`/nop/main/auth/app.data-auth.xml`文件中可以配置动态搜集所有模块下的data-auth配置

src/dev-guide/biz/validator.md

@@ -12,7 +12,7 @@
 模型文件中定义验证逻辑。validator内部可以分为多个check步骤，
 每个步骤对应一个判断条件，条件不匹配的时候将抛出对应的异常码和异常消息。
 
-具体判断条件的格式由元模型[filter.xdef](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-xdefs/src/main/resources/_vfs/nop/schema/query/filter.xdef)
+具体判断条件的格式由元模型[filter.xdef](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-kernel/nop-xdefs/src/main/resources/_vfs/nop/schema/query/filter.xdef)
 规定。
 在其中可以写and/or/not等嵌套条件，可以通过eq/gt/ge等实现比较判断。name属性对应于上下文环境中的变量以及变量上的属性。
 
@@ -46,7 +46,7 @@ Nop平台中的后台服务函数不一定在Java类中实现。在进行无代
 
 比如[Demo.xbiz](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-demo/nop-quarkus-demo/src/main/resources/_vfs/nop/demo/model/Demo/Demo.xbiz)
 模型中定义的
-testValidator2和testValidator3函数，它们的作用和[DemoBizModel](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-demo/nop-quarkus-demo/src/main/java/io/nop/demo/biz/DemoBizModel.java)
+testValidator2和testValidator3函数，它们的作用和[DemoBizModel](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-demo/nop-spring-simple-demo/src/main/java/io/nop/demo/biz/DemoBizModel.java)
 类中定义的testValidator函数的作用完全等价。
 
 testValidator3函数通过`biz:RunValidator`标签函数来装载外部的validator模型文件，并执行验证逻辑。这样做的好处是未来可以通过Delta定制机制来修改验证逻辑，而不用修改Demo.xbiz文件。
@@ -108,7 +108,7 @@ Demo.xbiz文件中的testValidator2函数演示了另外一种执行Validator验
 
 ## 模型注册
 
-通过[register-model.xml](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-core/src/main/resources/_vfs/nop/core/registry/validator.register-model.xml)
+通过[register-model.xml](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-kernel/nop-core/src/main/resources/_vfs/nop/core/registry/validator.register-model.xml)
 可以将自定义模型的加载器注册到Nop平台中，这样通过统一的ResourceComponentManager.loadComponentModel函数就可以加载平台中注册的所有种类的模型。
 
 ```xml

src/dev-guide/command/command.md

@@ -2,7 +2,7 @@
 
 Nop平台内置了命令行程序支持，只要注册ICommand接口的bean，就可以通过命令行指令直接调用。执行完指令后会直接推出应用
 
-## 1. 注册[ICommand](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-core/src/main/java/io/nop/core/command/ICommand.java)接口的实现类，bean的名称为nopCommand\_xxx
+## 1. 注册[ICommand](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-kernel/nop-core/src/main/java/io/nop/core/command/ICommand.java)接口的实现类，bean的名称为nopCommand\_xxx
 
 ```
   <bean id="nopCommand_test" class="test.TestCommand" />

src/dev-guide/config.md

@@ -28,7 +28,7 @@
 
 >
 
-具体配置加载逻辑全部集中在[ConfigStarter.java](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-config/src/main/java/io/nop/config/starter/ConfigStarter.java)
+具体配置加载逻辑全部集中在[ConfigStarter.java](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-core-framework/nop-config/src/main/java/io/nop/config/starter/ConfigStarter.java)
 类中
 
 * **在bootstrap.yaml或者application.yaml中可以配置nop.profile=dev来启用application-dev.yaml配置，类似于spring中的profile概念。**

src/dev-guide/delta/delta-customization.md

@@ -235,7 +235,7 @@ NopIoC更为强大的地方是它支持XLang语言内置的Delta定制机制。
     <bean id="nopDataSource" x:override="remove" />
 ```
 
-具体配置参见[delta目录下的dao-defaults.beans.xml](https://gitee.com/canonical-entropy/nop-for-ruoyi/blob/master/ruoyi-admin/src/main/resources/_vfs/_delta/default/nop/dao/beans/dao-defaults.beans.xml)
+具体配置参见[delta目录下的dao-defaults.beans.xml](https://www.gitee.com/nop-entropy/null)
 
 Delta定制非常简单直观，**适用于所有模型文件而且可以定制到最细粒度的单个属性**。如果对比一下SpringBoot的等价实现，我们会发现SpringBoot的定制功能存在很大的限制：首先，为了实现Bean exclusion和 Bean Override，Spring需要在引擎内部增加大量相关的处理代码，同时也引入很多特殊的使用语法。第二，Spring的定制机制只针对单个Bean的配置，比如我们可以禁用某个bean，但缺乏合适的针对单个属性的定制手段。如果事前规划的不好，我们很难通过简单的方式来覆盖系统中已有的Bean的定义。
 
@@ -297,7 +297,7 @@ Nop平台的前端页面主要在`view.xml`和`page.yaml`这两种模型文件
 ## 3.6 标签函数的Delta定制
 
 Nop平台的代码生成以及元编程机制中大量使用Xpl模板语言，而且工作流模型等可执行模型中所有涉及脚本执行的地方使用的都是Xpl模板语言。Xpl模板语言内置了标签库机制来实现函数级别的封装（每一个标签相当于是一个静态函数）。标签库xlib文件可以通过Delta定制机制来实现定制。
-例如我们可以定制[control.xlib](https://gitee.com/canonical-entropy/nop-app-mall/blob/master/app-mall-app/src/main/resources/_vfs/_delta/default/nop/web/xlib/control.xlib)来调整字段类型所对应的缺省展示控件，也可以定制[ddl.xlib](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-orm/src/main/resources/_vfs/nop/orm/xlib/ddl/ddl_mysql.xlib)来修复针对某个数据库版本的建表语句的语法。
+例如我们可以定制[control.xlib](https://www.gitee.com/nop-entropy/null)来调整字段类型所对应的缺省展示控件，也可以定制[ddl.xlib](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-persistence/nop-orm/src/main/resources/_vfs/nop/orm/xlib/ddl/ddl_mysql.xlib)来修复针对某个数据库版本的建表语句的语法。
 
 ## 3.7 规则模型和报表模型等的Delta定制
 
@@ -306,7 +306,7 @@ Nop平台中的所有模型，包括工作流模型、报表模型、规则模
 与一般的报表引擎、工作流引擎不同，Nop平台中的引擎大量使用了Xpl模板语言作为可执行脚本，因此可以引入自定义标签库来实现定制扩展。例如，
 一般的报表引擎会内置几种数据加载机制:JDBC/CSV/JSON/Excel等。如果我们希望增加新的加载方式，一般需要实现引擎内置的特殊接口，并且使用特殊的注册机制将接口实现注册到引擎中，而修改可视化设计器，使其支持自定义配置一般也不是一项很简单的工作。
 
-而在`NopReport`报表模型中，提供了名为`beforeExecute`的Xpl模板配置，它可以看作是一个基于通用接口（[IEvalAction](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-core/src/main/java/io/nop/core/lang/eval/IEvalAction.java)）的扩展点。在`beforeExecute`段中我们可以采用如下方式引入新的数据加载机制：
+而在`NopReport`报表模型中，提供了名为`beforeExecute`的Xpl模板配置，它可以看作是一个基于通用接口（[IEvalAction](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-kernel/nop-core/src/main/java/io/nop/core/lang/eval/IEvalAction.java)）的扩展点。在`beforeExecute`段中我们可以采用如下方式引入新的数据加载机制：
 
 ```xml
 <beforeExecute>

src/dev-guide/dict.md

@@ -1,7 +1,7 @@
 # 字典表翻译
 
 在ORM模型中可以直接定义字典表，并且可以为字段指定关联的字典表，然后在GraphQL层会自动为这些字段生成对应的label字段，
-比如status生成status\_label。参见[meta-gen.xlib](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-xlang/src/main/resources/_vfs/nop/core/xlib/meta-gen.xlib)中GenDictLabelFields标签的实现。
+比如status生成status\_label。参见[meta-gen.xlib](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-kernel/nop-xlang/src/main/resources/_vfs/nop/core/xlib/meta-gen.xlib)中GenDictLabelFields标签的实现。
 
 ## 为字段指定字典表
 

src/dev-guide/graphql/crud.md

@@ -332,7 +332,7 @@ filter对应于后台的TreeBean类型的对象，这是一个通用的Tree结
 }
 ```
 
-过滤条件中所支持的运算符如eq,gt等，都是[FilterOp.java](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-core/src/main/java/io/nop/core/model/query/FilterOp.java)
+过滤条件中所支持的运算符如eq,gt等，都是[FilterOp.java](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-kernel/nop-core/src/main/java/io/nop/core/model/query/FilterOp.java)
 中定义的操作符。
 重用的算符有：
 

src/dev-guide/graphql/graphql-java.md

@@ -84,9 +84,9 @@ NopGraphQL引擎在构造BizObject的时候还会检查xbiz扩展模型，我们
 操作往往是不同的业务对象中相似度最高的部分，因此有必要对它们进行统一抽象。NopGraphQL使用设计模式中的模板方法(Template
 Method)模式提供了通用的CRUD实现：CrudBizModel。具体使用方法是从CrudBizModel类继承，然后可以通过实现defaultPrepareSave/afterEntityChange等函数补充定制逻辑。参见代码
 
-[CrudBizModel.java](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-biz/src/main/java/io/nop/biz/crud/CrudBizModel.java)
+[CrudBizModel.java](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-core-framework/nop-biz/src/main/java/io/nop/biz/crud/CrudBizModel.java)
 
-[ObjMetaBasedValidator.java](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-biz/src/main/java/io/nop/biz/crud/ObjMetaBasedValidator.java)
+[ObjMetaBasedValidator.java](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-core-framework/nop-biz/src/main/java/io/nop/biz/crud/ObjMetaBasedValidator.java)
 
 [NopAuthUserBizModel.java](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-auth/nop-auth-service/src/main/java/io/nop/auth/service/entity/NopAuthUserBizModel.java)
 
@@ -235,7 +235,7 @@ filter对应于后台的TreeBean类型的对象，这是一个通用的Tree结
 }
 ```
 
-过滤条件中所支持的运算符如eq,gt等，都是[FilterOp.java](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-core/src/main/java/io/nop/core/model/query/FilterOp.java)
+过滤条件中所支持的运算符如eq,gt等，都是[FilterOp.java](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-kernel/nop-core/src/main/java/io/nop/core/model/query/FilterOp.java)
 中定义的操作符。
 重用的算符有：
 
@@ -556,7 +556,7 @@ public class DevDocBizModel {
 }
 ```
 
-完整实现参考[DevDocBizModel.java](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-biz/src/main/java/io/nop/biz/dev/DevDocBizModel.java)
+完整实现参考[DevDocBizModel.java](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-core-framework/nop-biz/src/main/java/io/nop/biz/dev/DevDocBizModel.java)
 
 ## 在XBiz模型中定义Loader