4.1.14 Search之非存储字段条件

相关推荐

• 组件介绍

  在设计页面时，页面中的所有内容均是由组件组成，每个组件有不同的属性，可以灵活的对每个组件的属性进行设置，以满足业务场景。 组件分为四类，分别是布局、字段、动作、数据 1. 布局 布局类组件主要用于页面的样式排版。 分组：类似一个容器，可以把业务含义相近的内容放在这个分组容器内。 选项卡：类似一个容器，每个选项卡可以添加多个选项页，可以把业务含义相近的内容放在选项卡的选项页容器内。 2. 字段 字段型组件是常用，也是用于支撑页面的主要组件类，每个字段型组件都对应一个模型字段。 单行文本：常用于记录名称、身份证号或其他普通的文字内容。 多行文本：常用于记录字数较多的文字，如意见、复杂备注等。 整数：常用于输入整数的天数、数量等，如果会出现小数，请使用小数组件。 小数：常用于输入金额、单价等，会出现小数的数值。 下拉单选：从多个选项中下拉选择一个数据，作为数据值。选项可以是关联模型的数据，也可以是数据字典或布尔型开关。 下拉多选：从多个选项中下拉选择多个数据，作为数据值。选项可以是关联模型的数据，也可以是数据字典。 开关：常用于只有是否两种对立选项的选择。 单选框：常用于在直接展示的选现中单选一个值，例如选择性别。 复选框：常用于在直接展示的选现中多选一个值，例如选择爱好、选择课程等。 富文本编辑器：一种可内嵌于浏览器，所见即所得的文本编辑器，类似于Office Word 的编辑功能，常应用于篇幅较长的说明性文字，支持改变字体样式、插入图片等。 年份：常用于选择出身年份、一项计划的年份等。 日期：常用于选择颗粒度到日期的Date类型字段，例如出生日期、入职日期、入驻日期等。 日期时间：常用于选择颗粒度到时间的DateTime类型的字段，例如下单时间、发货时间、审批时间等。 时间：常用于选择仅时间无日期的Time类型的字段，如设置规章中的上班时间、日志的提交时间等。 颜色选择器：应用于自定义颜色，如设置标签的颜色、设置产品的颜色属性、主题定制时选择色彩等。 文件上传：常用于上传附件、文件，例如Office文档、图片、视频、音频、其他格式的文件等。 图片上传：常用于上传记录的图片，例如上传身份证照片、头像、商品图片等。 标签：可输入保存多值，例如用户的标记标签。 3. 数据 与数据可视化设计器进行联动，可以选择自定义的图表或报表，在页面展示。 图表：可以选择数据可视化设计器中允许被引用的图表，展示在页面中 报表：可以选择数据可视化设计器中允许被引用的报表，展示在页面中

  史, 昂

  Oinone 7天入门到精通 2024年6月20日

  2.4K000

• 4.1.16 框架之网关协议-RQSL及扩展

  一、RSQL / FIQL parser RSQL是一种查询语言，用于对RESTful API中的条目进行参数化过滤。它基于FIQL（Feed Item Query Language）——一种URI友好的语法，用于跨Atom Feed中的条目表达过滤器。FIQL非常适合在URI中使用，没有不安全的字符，因此不需要URL编码。另一方面，FIQL的语法不太直观，URL编码也不总是那么重要，因此RSQL还为逻辑运算符和一些比较运算符提供了更友好的语法。 例如，您可以像这样查询资源：/movies?query=name=="Kill Bill";year=gt=2003 or /movies?query=director.lastName==Nolan and year>=2000。详见以下示例： 这是一个用JavaCC和Java编写的完整且经过彻底测试的RSQL解析器。因为RSQL是FIQL的超集，所以它也可以用于解析FIQL。 语法和语义 以下语法规范采用EBNF表示法（ISO 14977）编写。 RSQL表达式由一个或多个比较组成，通过逻辑运算符相互关联： Logical AND : ; or and Logical OR : , or or 默认情况下，AND运算符优先（即，在任何OR运算符之前对其求值）。但是，可以使用带括号的表达式来更改优先级，从而产生所包含表达式产生的任何结果。 input = or, EOF; or = and, { "," , and }; and = constraint, { ";" , constraint }; constraint= ( group | comparison ); group = "(", or, ")"; 比较由选择器、运算符和参数组成。 comparison=选择器、比较运算、参数； 选择器标识要筛选的资源表示形式的字段（或属性、元素…）。它可以是任何不包含保留字符的非空Unicode字符串（见下文）或空格。选择器的特定语法不由此解析器强制执行。 selector=未保留str； 比较运算符采用FIQL表示法，其中一些运算符还具有另一种语法： · Equal to : == · Not equal to : != · Less than : =lt= or < · Less than or equal to : =le= or <= · Greater than operator : =gt= or > · Greater than or equal to : =ge= or >= · In : =in= · Not in : =out= 您还可以使用自己的运算符简单地扩展此解析器（请参阅下一节）。 comparison-op = comp-fiql | comp-alt; comp-fiql = ( ( "=", { ALPHA } ) | "!" ), "="; comp-alt = ( ">" | "<" ), [ "=" ]; 参数可以是单个值，也可以是用逗号分隔的括号中的多个值。不包含任何保留字符或空格的值可以不加引号，其他参数必须用单引号或双引号括起来。 arguments = ( "(", value, { "," , value }, ")" ) | value; value = unreserved-str | double-quoted | single-quoted; unreserved-str = unreserved, {…

  史, 昂

  Oinone 7天入门到精通 2024年5月23日

  1.9K000
• Oinone 7天入门到精通

  5.1 CDM的背景介绍

  如果说低代码开发框架输出技术标准，CDM则是结合oinone技术特性和软件工程设计，让输出数据标准变成可能。 一、背景介绍 无法照搬的最佳实践 要了解引入CDM的初衷，得从互联网架构的演进开始，了解其过程，就知道为什么说Oinone的CDM是中台架构的最佳技术实践的核心！我们在2.2【互联架构做为最佳实践为何失效】一文中介绍过互联网技术发展的四个阶段，特别平台化到中台化的阶段，目的是在一套规范下让听的见炮火声音的团队自行决定业务系统发展，适用多业务线（或多场景应用）独立发展。 互联网架构在演进过程中碰到的问题跟企业数字化转型过程中碰到的问题是非常类似： 随着企业业务在线化后对系统性能、稳定都提出了更高的要求，而且大部分企业的内部很多系统相互割裂导致，导致很多重复建设，所以我们需要服务化、平台化。 同时没有一个供应商能解决企业所有商业场景问题，又需要多个供应商共同参与，所以把供应商类类比成各个业务线，在一套规范下让供应商自行决定业务系统发展 既然跟阿里当初在架构演进过程中碰到的问题非常类似，那么是不是照搬阿里中台架构方案到企业就好了？当然不是，因为历史原因阿里的中台架构是采用的平台共建模式：“让业务线研发以平台设计好的规范进来共同开发”，其本质还是平台主导模式，它是有非常大的历史包袱。我们想象各个供应商的共建一个交易平台或商品平台，那是多么荒唐的事情，平台化已经足够的复杂了，还让不同背景、不同企业的研发一起共建，最后往往导致企业架构负载过重，这时对企业来说便不再是赋能而是“内耗”。 那么如果没有历史包袱，我们重新设计，站在上帝视角去看有没有更好的方式呢？当然有 借鉴微软的CDM 这里我们借鉴微软的CDM理念，CDM这个概念最早是2016年微软宣布“以Dynamics 365的形式改造其CRM和ERP”战略时提出的。微软给它的定义是“用于存储和管理业务实体的业务数据库，而且是开箱即用的”。CDM不仅仅提供标准实体，它还允许用户建立个性化的实体，用户可以扩展标准实体也可以增加和标准实体相关的新实体。 CDM可能并不性感，但绝对是非常必要的。它成为了微软的很多产品的基础，是构建了无数业务领域的原型。同时微软也期望它能成为快速实现数据交换和迁移的标准，这个有点像菜鸟网络推出的奇门，让所有TMS、OMS、WMS都基于一套数据接口API进行互通，一套标准是为了解决一个行业问题，而不是具体某一个企业一个集团的问题。 我们发现CDM的理念跟我们想要的“企业级的数据标准”是非常吻合的。但是我们也不能照搬照抄，虽然微软的CDM很好的解决了数据割裂问题，但就模型来说就够大家喝一壶了，模型库非常庞大而且复杂，学习成本巨高。 数字化时代软件会产生新的技术流派 我们知道传统软件的设计理念：侧重在模型对业务支撑全面性上。优点体现为配置丰富，缺点模型设计过于复杂，刚开始有前瞻性，但在理解、维护都非常困难，随着业务发展系统原先的设计逐渐腐化，异常笨重。 而Oinone的CDM设计理念：侧重在简单、灵活、统一上，体现为在上层应用开发时，每一业务领域保持独立，模型简单易懂，并结合Oinone的低代码开发机制进行快速开发，灵活应对业务变化。 所以我更想说Oinone的CDM是微软CDM的在原有基础上，与互联网架构结合，利用Oinone低代码开发平台特性形成新的工程化建议。Oinone-CDM不以把模型抽象到极致，支撑“所有业务可能性”为目标，而是抽象80%通用的设计，保持模型简单可复用，来解决数据割裂问题，并保持业务线独立自主性，快速创新的能力。 图5-1-1 Oinone-CDM要解决的问题 二、Oinone的CDM本质是创新的工程化建议 引入CDM以后系统工程结构会有什么变化，跟大家认知的互联网架构有什么区别。 原本上层的业务线系统，需要调用各个业务平台提供的功能，增加CDM以后也就是我们右的图，每个业务线就像一个独立右边。看上去复杂了，其实对业务线来说更加简单了。 互联网整体平台化带来的问题： 业务线每次业务调整都需要给各个平台提需求 业务平台研发需要了解所有业务线的知识再做设计，对研发要求非常高 各个业务域的不同需求相互影响包括系统稳定性、研发对需求响应的及时性 结合oinone特性提出的新工程建议： 一些通用性模块继续以平台化的方式存在，能力完全复用。 业务线自建业务平台，保持业务线的独立性和敏捷性 业务线以CDM为原型，保证核心数据不割裂，形成一致的数据规范 图5-1-2 引入CDM概念后的工程结构对比 三、CDM思路示意图 该示例中OinoneCDM的商品域不仅仅提供标准实体，保证各个业务系统的对商品的通用需求、简单易懂，在我们星空系列业务产品中如全渠道运营、B2B交易等系统以此为基础建立属于自身个性化的实体，可以扩展标准实体也可以增加和标准实体相关的新实体。 带来的好处： 通过多种继承方式，继承后的模型可扩展模型本身、模型行为等，从而解决业务独立性问题。 通过CDM层统一数据模型，从而解决多应用数据割裂问题 图5-1-3 Oinone-CDM思路示意图

  史, 昂

  2024年5月23日

  1.3K000
• Oinone 7天入门到精通

  3.5.2.1 整体介绍

  虽然我们有小眼睛可以让用户自定义展示字段和排序喜好，以及通过权限控制行、列展示，但在我们日常业务开发中还是会对页面进行调整，以满足业务方的对交互友好和便捷性的要求。本节会在如何自定义之前我们先介绍页面结构与逻辑，再带小伙伴一起完成自定义view的Template和Layout，以及整个母版的Template和Layout 页面的构成讲解 页面交互拓扑图 页面交互拓扑图 图3-5-2-1 页面交互拓扑图 注：页面逻辑交互拓扑图说明 模块作为主切换入口 模块决定菜单列表 菜单切换触发点击action 前端根据Mask、View进行渲染， a. Mask是母版是确定了主题、非主内容分发区域所使用组件和主内容分发区域联动方式的页面模板。全局、应用、视图动作、视图都可以通过mask属性指定母版 bMask和View都是有layout定义和template定义合并而成，系统会提供默认母版，以及为每种视图提供默认layout c. layout与template通过插槽进行匹配 Action根据不同类型做出不同访问后端服务、url跳转、页面路由、发起客户端动作等 Aciton路由可以指定Mask、视图组件的layout、template a. 当layout没有指定的时候则用系统默认的 b. 当template没有指定的时候，且视图组件相同类型有多条记录时，根据优先级选取 Mask和视图组件的layout优先级（视图组件>视图动作 > 应用 > 全局） 默认母版以及各类视图组件 母版布局 默认母版基础布局base-layout <mask layout="default"> <header slot="header"/> <container slot="main" name="main"> <sidebar slot="sidebar"/> <container slot="content"/> </container> <footer slot="footer"/> </mask> 图3-5-2-2 默认母版基础布局base-layout 母版template <mask layout="default"> <mask name="defaultMask"> <template slot="header"> <container name="appBar"> <element widget="logo"/> <element widget="appFinder"/> </container> <container name="operationBar"> <element widget="notification"/> <element widget="dividerVertical"/> <element widget="languages"/> </container> <element widget="userProfile"/> </template> <template slot="sidebar"> <element widget="navMenu"/> </template> <template slot="content"> <element widget="breadcrumb"/> <element widget="mainView"/> </template> </mask> 图3-5-2-3 母版template 注： 上例中因为名称为main的插槽不需要设置更多的属性，所以在template中缺省了main插槽的template标签。 最终可执行视图 <mask name="defaultMask"> <header> <container name="appBar"> <element widget="logo"/> <element widget="appFinder"/> </container> <container name="operationBar"> <element widget="notification"/> <element widget="dividerVertical"/> <element widget="languages"/> </container> <element widget="userProfile"/> </header> <container name="main"> <sidebar name="sidebar"> <element widget="navMenu"/> </sidebar> <container name="content"> <element widget="breadcrumb"/> <element widget="mainView"/> </container> </container> <footer/> </mask> 图3-5-2-4 最终可执行视图 表格视图布局 默认表格视图基础布局base-layout <view type="table"> <view type="search"> <element widget="search" slot="search"> <xslot name="fields" slotSupport="field" /> </element> </view> <pack widget="fieldset"> <element widget="actionBar" slot="actions" slotSupport="action" /> <element widget="table" slot="table"> <xslot name="fields" slotSupport="field" /> <element widget="actionsColumn" slot="actionsColumn"> <xslot name="rowActions" slotSupport="action" /> </element> </element> </pack> </view> 图3-5-2-5 默认表格视图基础布局base-layout 注：table标签的子标签为column组件，如果field填充到元数据插槽fields没有column组件将自动包裹column组件。 表格视图template <view type="table" model="xxx" name="tableViewExample">…

  史, 昂

  2024年5月23日

  1.6K000
• Oinone 7天入门到精通

  2.4 Oinone的三大独特性

  Oinone在技术方面通过整合互联网架构和低代码技术，实现了三个独特的关键创新点（如图2-5所示）： 独立模块化的个性化定制：每个需求都可以被视为一个独立的模块，从而实现个性化定制，提高软件生产效率。此外，这些独立模块也不会影响产品的迭代和升级，为客户带来无忧的体验。 灵活的部署方式：单体部署和分布式部署的灵活切换，为企业业务的发展提供了便利，同时适用于不同规模的公司，有助于有效地节约企业成本，提升创新效率，并让互联网技术更加亲民。 低代码和无代码的结合：低无一体为不同的IT组织和业务用户提供了有效的协同工作方式，能够快速部署安全、可扩展的应用程序和解决方案，帮助企业/组织更好地管理业务流程并不断优化。 图2-5 Oinone的三大独特性

  史, 昂

  2024年5月23日

  2.2K000