canonical

Results 9 issues of canonical

- gitee: [canonical-entropy/nop-entropy](https://gitee.com/canonical-entropy/nop-entropy) - github: [entropy-cloud/nop-entropy](https://github.com/entropy-cloud/nop-entropy) - 开发示例:[docs/tutorial/tutorial.md](https://gitee.com/canonical-entropy/nop-entropy/blob/master/docs/tutorial/tutorial.md) - [可逆计算原理和Nop平台介绍及答疑_哔哩哔哩_bilibili](https://www.bilibili.com/video/BV1u84y1w7kX/) Nop Platform 2.0是基于可逆计算原理从零开始构建的新一代低代码平台,它致力于克服低代码平台无法摆脱穷举法的困境,从理论层面超越组件技术,有效的解决粗粒度软件复用的问题。 - nop-entropy支持GraalVM技术,可以借助于[Quarkus](https://quarkus.io/) 或者[SpringNative](https://docs.spring.io/spring-native/docs/current/reference/htmlsingle/)框架编译为原生可执行程序,运行时不需要安装JDK,且启动速度提升数十倍。 - **nop-entropy的设计目标是成为简单易用的领域语言工作台(Domain Language Workbench)**。通过增加简单的元数据定义,就可以自动得到对应的解析器、验证器、IDE插件、调试工具等,并自动为DSL领域语言增加模块分解、差量定制、元编程等通用语言特性。在这一点上,它类似于Jetbrains公司的[MPS产品](https://www.jetbrains.com/mps/),只是它的设计原理和技术实现路径与MPS有着本质性差别。 - nop-entropy采用云原生设计,内置分布式事务和多租户支持,可以单机运行,也可以作为分布式集群运行,可以提供在线的API服务,也可以将针对单个业务对象的在线服务自动包装为针对批处理文件的批处理任务。对于大多数业务应用场景均提供相应的模型支持,只需少量配置即可完成主要功能,大大降低对手工编码的需求。 - nop-entropy在开发期可以作为**支持增量式开发的低代码平台**,自动生成各类代码以及相关文档,在运行期可以作为**面向最终用户的无代码平台的支撑技术**,允许客户在线调整业务模块功能,以所见即所得的方式进行产品迭代。 Nop平台现在内置了一个演示用的软件生产线,可以从Excel格式的数据模型自动生成GraphQL服务以及前端页面,然后在自动生成的代码基础上我们可以手工调整,手工编写的差量代码与自动生成的代码相互隔离,不会相互影响。 ![delta-pipeline](https://gitee.com/canonical-entropy/nop-entropy/raw/master/docs/tutorial/delta-pipeline.png) 实际上,基于Nop平台开发的软件产品都支持Delta定制机制,应用层代码无需做出任何特殊的设计(比如预先抽象出扩展接口)即可获得完全增量式的定制化开发能力(定制的增量代码完全独立于基础产品代码,定制基础产品或者Nop平台的功能都无需修改原始代码 [如何在不修改基础产品源码的情况下实现定制化开发](https://zhuanlan.zhihu.com/p/628770810) 为自定义的DSL提供断点调试、语法提示等功能 ![debugger](https://gitee.com/canonical-entropy/nop-entropy/raw/master/docs/tutorial/xlang-debugger.png)...

[https://zhuanlan.zhihu.com/p/64004026](https://zhuanlan.zhihu.com/p/64004026) 组件技术的内在假定是“相同可以复用”,但是A和B的公共部分是比A和B都要小的,这使得组件技术在理论层面就难以解决粗粒度软件复用的问题。要解决系统级别的软件复用,我们需要在软件构造理论方面做出新的发展。 在最近几年的技术实践中,Docker、React、k8s的Kustomize等基于差量概念的技术层出不穷,在所有这些Ad Hoc的实践背后存在统一的软件构造规律。可逆计算提出了一个基于可逆差量运算的软件构造公式: ```` App = Delta x-extends Generator ```` 它可以为各种实践提供统一的理论解释,并为它们指明进一步发展的方向。比如 ```` DockerApp = DockerBuilder overlay-fs BaseImage ```` 为了更好的展示可逆计算理论的具体技术内涵,我开源了一个面向DSL开发的低代码平台Nop Platform 2.0,它的目标类似于JetBrains公司的MPS产品,希望实现一个快速开发和扩展DSL的领域语言工作台(Domain Language Workbench ),但它的具体实现方式与MPS有本质不同。 https://github.com/entropy-cloud/nop-entropy Nop平台现在内置了一个演示用的软件生产线,可以从Excel格式的数据模型自动生成GraphQL服务以及前端页面,然后在自动生成的代码基础上我们可以手工调整,手工编写的差量代码与自动生成的代码相互隔离,不会相互影响。 ![delta-pipeline](https://gitee.com/canonical-entropy/nop-entropy/raw/master/docs/tutorial/delta-pipeline.png) 实际上,基于Nop平台开发的软件产品都支持Delta定制机制,应用层代码无需做出任何特殊的设计(比如预先抽象出扩展接口)即可获得完全增量式的定制化开发能力(定制的增量代码完全独立于基础产品代码,定制基础产品或者Nop平台的功能都无需修改原始代码 [如何在不修改基础产品源码的情况下实现定制化开发](https://zhuanlan.zhihu.com/p/628770810)

项目地址: https://github.com/entropy-cloud/nop-entropy 演示视频: https://www.bilibili.com/video/BV1Sa4y1K7tD/ 中国式报表是复杂结构报表的代名词,它泛指国内信息化领域经常出现的基于多源数据,采用行列交叉、多层级表头、自由分片合并等形式所展现的信息汇总报表。目前国内商业化的报表工具都支持中国式报表的制作,但是开源的报表引擎中只有[UReport](https://gitee.com/youseries_admin/ureport)支持中国式报表,而且目前已经不再维护。 NopReport是基于可逆计算理论从零开始独立实现的一套开源中国式报表引擎,它的核心代码很短,只有3000多行(参见[nop-report-core](https://gitee.com/canonical-entropy/nop-entropy/tree/master/nop-report/nop-report-core)模块),具有较高的性能(性能测试代码参见[TestReportSpeed.java](https://gitee.com/canonical-entropy/nop-entropy/blob/master/nop-report/nop-report-demo/src/test/java/io/nop/report/demo/TestReportSpeed.java)),以及其他报表引擎难以达到的灵活性和可扩展性。 NopReport是Nop平台内置的报表引擎,它可以独立于Nop平台被第三方软件所使用。NopReport的体积很小,使用了自己编写的XML解析器,不依赖于POI包,直接读写XLSX格式的Excel文件,可以在Android平台上运行,可以制作各类常见的复杂中国式报表。 # 示例截图: ## 档案式报表 ![](https://gitee.com/canonical-entropy/nop-entropy/raw/master/docs/user-guide/report/profile-report.png) ![](https://gitee.com/canonical-entropy/nop-entropy/raw/master/docs/user-guide/report/profile-report-result.png) ## 段落明细表 ![](https://gitee.com/canonical-entropy/nop-entropy/raw/master/docs/user-guide/report/block-report.png) ![](https://gitee.com/canonical-entropy/nop-entropy/raw/master/docs/user-guide/report/block-report-result.png) ## 复杂多源报表 ![](https://gitee.com/canonical-entropy/nop-entropy/raw/master/docs/user-guide/report/multi-ds-report.png) ![](https://gitee.com/canonical-entropy/nop-entropy/raw/master/docs/user-guide/report/multi-ds-report-result.png) ## 交叉报表—数据双向扩展 ![](https://gitee.com/canonical-entropy/nop-entropy/raw/master/docs/user-guide/report/cross-table-report.png) ![](https://gitee.com/canonical-entropy/nop-entropy/raw/master/docs/user-guide/report/cross-table-report-result.png) ## 同比环比等财务统计表 ![](https://gitee.com/canonical-entropy/nop-entropy/raw/master/docs/user-guide/report/MOM-YOY-report.png) ![](https://gitee.com/canonical-entropy/nop-entropy/raw/master/docs/user-guide/report/MOM-YOY-report-result.png) #...

- 项目地址:https://github.com/entropy-cloud/nop-entropy - 类别:Java - 项目标题:基于可逆计算原理从零开始构建的低代码平台:Nop平台 - 项目描述: Nop平台的设计目标是成为简单易用的领域语言工作台,可以快速开发和定制DSL。然后再利用这些DSL来开发业务软件。平台已内置了ORM、工作流、视图模型、GraphQL模型等大量开发常用模型。 - 亮点: * 支持GraalVM编译 * 通过增加简单的元数据定义,就可以自动得到对应的解析器、验证器、IDE插件、调试工具等,并自动为DSL领域语言增加模块分解、差量定制、元编程等通用语言特性。 * 支持Delta定制。任何使用Nop平台开发的产品都可以在不修改产品源码的情况下实现定制化开发。定制代码独立于基础产品代码存放 * 根据Excel数据模型自动生成前后端全套代码,包括后端的GraphQL服务和前端的AMIS页面 * 采用Excel作为可视化设计器来设计中国式报表、业务规格、数据模型、API模型等 * 无需编写代码即可实现将Excel解析为任何复杂领域对象或者根据领域对象生成Excel的功能(EasyExcel等只能实现平面结构的输出)。 * 各个部分可以独立使用。它的代码生成器、ORM、IoC容器、工作流、报表引擎、规则引擎、GraphQL引擎等都是从第一性原理出发从零开始设计实现的,提供了大量开源框架所没有的创新功能。这些模块相互之间也没有依赖,可以独立集成在其他项目中使用。 - 截图: 为自定义的DSL提供断点调试、语法提示等功能 ![debugger](https://gitee.com/canonical-entropy/nop-entropy/raw/master/docs/tutorial/xlang-debugger.png) 通过Excel设计数据模型...

## 推荐项目 - 项目地址:https://github.com/entropy-cloud/nop-entropy - 类别:Java - 项目标题:基于可逆计算原理从零开始构建的低代码平台 - 项目描述: Nop平台的设计目标是成为简单易用的领域语言工作台,可以快速开发和定制DSL。然后再利用这些DSL来开发业务软件。平台已内置了ORM、工作流、视图模型、GraphQL模型等大量开发常用模型。 - 亮点: * 支持GraalVM编译 * 通过增加简单的元数据定义,就可以自动得到对应的解析器、验证器、IDE插件、调试工具等,并自动为DSL领域语言增加模块分解、差量定制、元编程等通用语言特性。 * 支持Delta定制。任何使用Nop平台开发的产品都可以在不修改产品源码的情况下实现定制化开发。定制代码独立于基础产品代码存放 * 根据Excel数据模型自动生成前后端全套代码,包括后端的GraphQL服务和前端的AMIS页面 * 采用Excel作为可视化设计器来设计中国式报表、业务规格、数据模型、API模型等 * 无需编写代码即可实现将Excel解析为任何复杂领域对象或者根据领域对象生成Excel的功能(EasyExcel等只能实现平面结构的输出)。 * 各个部分可以独立使用。它的代码生成器、ORM、IoC容器、工作流、报表引擎、规则引擎、GraphQL引擎等都是从第一性原理出发从零开始设计实现的,提供了大量开源框架所没有的创新功能。这些模块相互之间也没有依赖,可以独立集成在其他项目中使用。 - 截图: 为自定义的DSL提供断点调试、语法提示等功能...

Java 项目

- 项目名称:Nop低代码平台 - 项目地址:https://github.com/entropy-cloud/nop-entropy - 项目简介 (**100** 字以内): Nop平台的设计目标是成为简单易用的领域语言工作台,可以快速开发和定制DSL。然后再利用这些DSL来开发业务软件。平台已内置了ORM、工作流、视图模型、GraphQL模型等大量开发常用模型。 - 项目截图 (**6**张以内): 为自定义的DSL提供断点调试、语法提示等功能 ![debugger](https://gitee.com/canonical-entropy/nop-entropy/raw/master/docs/tutorial/xlang-debugger.png) 通过Excel设计数据模型 ![excel-data-model](https://gitee.com/canonical-entropy/nop-entropy/raw/master/docs/tutorial/excel-model.png) 通过Excel设计业务规则 ![excel-decision-tree](https://gitee.com/canonical-entropy/nop-entropy/raw/master/docs/dev-guide/rule/decision-tree.png) ![excel-decision-matrix](https://gitee.com/canonical-entropy/nop-entropy/raw/master/docs/dev-guide/rule/decision-matrix.png) 集成AMIS可视化设计器 ![amis-designer](https://gitee.com/canonical-entropy/nop-entropy/raw/master/docs/tutorial/amis-editor-view.png) 参考 [模板](https://github.com/GitHubDaily/GitHubDaily/issues/8)

Nop低代码平台中包含了一个开源的中国式报表引擎NopReport。我在NopReport中集成了集算器的功能,可以使用SPL为NopReport提供数据。介绍视频 https://www.bilibili.com/video/BV1Km4y1m7y2/。在集成SPL的过程中,我感觉有一些可以改进的地方: 1. SPL的设计器可以和运行时分开,这样更容易升级到高版本JDK上,也便于集成到Quarkus等框架中,使用GraalVM技术编译为exe。 2. SPL的配置文件可以按照可逆计算原理进行改造,这样esProcFunctions_zh.xml这样的配置可以内置在jar包中,但是我们需要增强的时候,可以采用如下方式进行扩展 ```xml 这里只写扩展配置,可以覆盖系统内置配置 ``` 具体原理可以参见我的文章 [ XDSL:通用的领域特定语言设计](https://zhuanlan.zhihu.com/p/612512300) 3. SPL可以将编译和运行分开。这样编译得到某种AST语法树之后,可以增加一些语义方面的限制和校验,比如限制文件路径必须符合某种模式等。或者在Context上增加一个ResourceLoader机制,把文件获取完全隔离到某个用户可定制的接口中,而不是直接在home目录下拼接子目录。目前的代码实现似乎是有安全漏洞的,通过../../../这种相对路径似乎可以突破目录限制访问到外部目录。

现在只有在配置了ConfigComponent的情况下才会通过onChange触发点击节点的回调通知。但是更灵活的界面组织需要在不使用内置的ConfigComponent机制的情况下也得到相应通知,然后动态选择如何处理,例如根据节点类型不同,动态选择drawer/dialog/property editor等编辑控件,显示位置也不同。 目前我在低代码平台NopPlatform中想集成FlowBuilder作为审批流的配置控件,我们会根据一个元模型配置动态生成前端的流程设计器,而不是在前端写死设计器的代码,所以需要更灵活的配置机制。希望能开放相关回调接口 https://github.com/entropy-cloud/nop-entropy

Nop平台的开发在https://gitee.com/canonical-entropy/nop-entropy 进行,github项目仅作为gitee项目的备份