3.5.7.2 自定义母版

母版是什么

在业务系统中,母版是一种全局通用的组件,用于包裹每个页面的元素。这个概念类似于 PPT 中的母版,它定义了页面的整体结构、样式和布局,使得系统具有一致的外观和风格。

特点:

  1. 全局通用:母版是全局性的,适用于系统中的每个页面,确保一致性的用户体验。

  2. 包裹元素:母版包裹每个页面的元素,定义了整体的结构和布局。

  3. 外观一致性:通过统一的母版设计,系统达到外观和风格的一致性。

与 PPT 母版的类比:

在母版的概念上,与 PPT 中的母版类似,都是用于定义整体结构和样式,确保每个页面都具有一致的外观。

默认母版范围:

image.png

图3-5-7-20 默认母版范围

作用场景

在系统中,我们提供了多个纬度的母版,包括全局、应用和页面纬度。这样的设计允许根据不同的业务场景选择合适的母版纬度,以满足不同层次的定制需求。

母版纬度:

  1. 全局母版:

    • 覆盖系统中所有页面,确保全局的一致性和统一的用户体验。
    • 定义全局性的结构、样式和布局。
  2. 应用母版:

    • 适用于特定应用或模块,定制化程度介于全局和页面之间。
    • 允许在不同应用间实现一定的差异化。
  3. 页面母版:

    • 面向具体页面,提供最大的定制化空间。
    • 允许在不同页面中定义不同的结构和样式。

选择纬度:

  • 业务场景决定:根据具体的业务场景和需求选择合适的母版纬度。
  • 定制化需求:如果需要全局一致性,选择全局母版;如果在应用层面有特定需求,选择应用母版;如果需要最大的灵活性和定制化,选择页面母版。

参数说明:

在系统中,使用 registerMask 注册母版时,需要提供两个参数。第一个参数是母版的 XML,第二个参数用于控制母版的注册行为,包括 module、moduleName、model 和 actionName。

  1. 母版 XML(第一个参数):

    • 提供母版的 XML 描述,定义了母版的结构和样式。
  2. 控制参数(第二个参数):

    • module:指定模块的名称。
    • moduleName:指定模块的显示名称。
    • model:指定母版所属的模型。
    • actionName:指定母版的操作名称,可以是字符串或字符串数组。

全局母版

可以使用 registerMask 注册母版。当第二个参数为 {} 时,即代表注册全局母版。

示例工程目录

以下是需关注的工程目录示例,并确保导入导出依赖正确:

image.png

图3-5-7-21 全局纬度注册母版工程目录示例

示例代码

以下是一个示例代码:

import { registerMask } from '@kunlun/dependencies';

/**
 * mask: 在做系统时,我们通常会把外层的布局(菜单、顶部导航)等抽出公共组件,公共组件会抽离全局通用。类似ppt母版的概念即为Mask
 * registerMask 第二个入参为{}即注册了全局得母版
 *
 * 和默认母版相比移除右上角消息、语言切换、用户
 * `<block>
 *     <widget widget="notification" />
 *     <widget widget="divider" />
 *     <widget widget="language" />
 *     <widget widget="divider" />
 *     <widget widget="user" />
 * </block>`
 */
const registerGlobalMask = () => {
    registerMask(`
    <mask>
        <multi-tabs />
        <header>
            <widget widget="app-switcher" />
        </header>
        <container>
            <sidebar>
                <widget widget="nav-menu" height="100%" />
            </sidebar>
            <content>
                <breadcrumb />
                <block width="100%">
                    <widget width="100%" widget="main-view" />
                </block>
            </content>
        </container>
    </mask>`, {});
}

registerGlobalMask();

图3-5-7-22 全局纬度注册母版代码示例

复制这段代码执行下registerGlobalMask()试试看吧

效果

右上角消息、语言切换、用户被移除。

image.png

图3-5-7-23 全局纬度注册母版效果示例

应用母版

在系统中,可以使用 registerMask 注册母版。当第二个参数为 {moduleName: 'resource'} 时,即注册了 resource(资源)应用的母版。

示例工程目录

以下是需关注的工程目录示例,更新导出./moduleMask:

image.png

图3-5-7-24 应用纬度注册母版工程目录示例

示例代码

以下是一个示例代码:

/**
 * registerMask 第二个入参为{moduleName: 'resource'}即注册了resource(资源)应用的母版
 *
 * resource来源: 通常是浏览器url上的module
 *
 * 和默认模版相比拿掉了菜单
 * `<sidebar>
 *    <widget widget="nav-menu" height="100%" />
 *  </sidebar>`
 * */
const registerModuleMask = () => {
    registerMask(`<mask>
    <multi-tabs />
    <header>
        <widget widget="app-switcher" />
        <block>
            <widget widget="notification" />
            <widget widget="divider" />
            <widget widget="language" />
            <widget widget="divider" />
            <widget widget="user" />
        </block>
    </header>
    <container>
        <content>
            <breadcrumb />
            <block width="100%">
                <widget width="100%" widget="main-view" />
            </block>
        </content>
    </container>
</mask>`, { moduleName: 'resource'})
}

registerModuleMask();

图3-5-7-25 应用纬度注册母版代码示例

在这个示例中,通过将第二个参数设置为 {moduleName: 'resource'},实现了注册 resource 应用的母版。该母版包含了特定于 resource 应用的全局结构和布局,并在示例中去掉了菜单部分。

这样的设计使得可以根据不同应用注册不同的母版,以满足应用层面的定制需求。

效果

image.png

图3-5-7-26 应用纬度注册母版效果示例

页面母版

在系统中,可以使用 registerMask 注册母版。当第二个参数为 {moduleName: 'resource', model: 'resource.ResourceRegionProxyModel'} 时,即注册了 resource(资源)应用和 这个应用下ResourceRegionProxyModel(地区)模型的母版。

示例工程目录

以下是需关注的工程目录示例,更新导出./viewMask:

image.png

图3-5-7-27 页面纬度注册母版工程目录示例

示例代码

以下是一个示例代码:

/**
 * registerMask 第二个入参为{moduleName: 'resource', model: 'resource.ResourceRegionProxyModel'}即注册了resource(资源)和resource.ResourceRegionProxyModel(地区)模型的母版
 *
 * resource来源: 通常是浏览器url上的module
 * model来源:  通常是浏览器url上的model
 *
 * 拿掉菜单
 * `<sidebar>
 *    <widget widget="nav-menu" height="100%" />
 *  </sidebar>`
 *
 *  拿掉appFounder
 *  `<widget widget="app-switcher" />`
 * */
const registerViewMask = () => {
  registerMask(`<mask>
    <multi-tabs />
    <header>
        <block>
            <widget widget="notification" />
            <widget widget="divider" />
            <widget widget="language" />
            <widget widget="divider" />
            <widget widget="user" />
        </block>
    </header>
    <container>
        <content>
            <breadcrumb />
            <block width="100%">
                <widget width="100%" widget="main-view" />
            </block>
        </content>
    </container>
</mask>`, { moduleName: 'resource', model: 'resource.ResourceRegionProxyModel'})
}
registerViewMask();

图3-5-7-28 页面纬度注册母版代码示例

在这个示例中,通过将第二个参数设置为 {moduleName: 'resource', model: 'resource.ResourceRegionProxyModel'},实现了注册 Resource 应用和 ResourceRegionProxyModel 模型的母版。该母版包含了特定于这两个条件的全局结构和布局,并在示例中去掉了菜单和应用切换部分。

效果

image.png

图3-5-7-29 页面纬度注册母版效果示例

这样的设计使得可以根据不同应用和模型注册不同的母版,以满足不同层次的定制需求

扩展母版

在系统中,除了平台内置的母版组件和布局外,开发者还可以自由地添加自定义的组件和布局,以决定应用的个性化。以下是一些示例代码和说明:

注册母版组件

在这个示例中,我们注册了一个名为 custom-mask-widget 的自定义组件,并使用 CustomMaskWidget 类初始化了该组件。

示例工程目录

以下是需关注的工程目录示例,更新导出./widget:

image.png

图3-5-7-30 扩展母版工程目录示例

示例代码

以下是代码示例和相应的组件实现:

1. 注册自定义组件:

import { SPI, MaskWidget } from '@kunlun/dependencies'
import CustomMaskWidgetVue from './MaskWidget.vue'

@SPI.ClassFactory(MaskWidget.Token({ widget: 'custom-mask-widget' }))
export class CustomMaskWidget extends MaskWidget {
  public initialize(props) {
    super.initialize(props);
    this.setComponent(CustomMaskWidgetVue);
    return this;
  }
}

图3-5-7-31 注册自定义组件(TS)示例

在这段代码中,我们使用 @SPI.ClassFactory 注解来创建 CustomMaskWidget 类,并使用 MaskWidget.Token 注入组件的标识。通过 setComponent 方法,我们将组件与 CustomMaskWidgetVue 相关联。

2. 自定义组件实现(MaskWidget.vue):

  <template>
    <div class="mask-widget-wrapper">
      <h1>Mask组件</h1>
    </div>
  </template>

  <script lang="ts">
    import { defineComponent } from 'vue'

    export default defineComponent({
      inheritAttrs: false,
      name: 'CustomMaskWidgetVue'
    })
  </script>

  <style lang="scss">
    .mask-widget-wrapper {
      display: flex;
      align-items: center;
      background-color: var(--oio-disable-color);
      h1 {
        color: red;
      }
    }
  </style>

图3-5-7-32 注册自定义组件(Vue)示例

在 MaskWidget.vue 文件中,我们定义了 CustomMaskWidgetVue 组件的模板、逻辑和样式。这个组件简单地展示了一个包含标题的容器。

通过这个示例,我们展示了如何使用 SPI 和 Vue 来注册和实现自定义组件,以满足系统中的个性化需求

自定义母版

在这个示例中,我们注册了一个全局母版,并将自定义组件 custom-mask-widget 与母版结合。

示例工程目录

以下是需关注的工程目录示例,新导出了./globalMask:

image.png

图3-5-7-33 自定义母版工程目录示例

示例代码

以下是代码示例:

const registerGlobalMask = () => {
  registerMask(`
    <mask>
        <multi-tabs />
        <header>
            <widget widget="language" />
+            <widget widget="custom-mask-widget" />
        </header>
        <container>
            <sidebar>
                <widget widget="nav-menu" height="100%" />
            </sidebar>
            <content>
                <breadcrumb />
                <block width="100%">
                    <widget width="100%" widget="main-view" />
                </block>
            </content>
        </container>
    </mask>`, {});
}

registerGlobalMask();

图3-5-7-34 自定义母版组件使用示例

在这段代码中,我们使用 registerMask 注册了一个全局母版,其中包含了多个内置组件和布局元素。通过 的方式,我们将自定义组件 custom-mask-widget 添加到了母版的头部(header)中

效果

image.png

图3-5-7-35 自定义母版效果示例

Oinone社区 作者:史, 昂原创文章,如若转载,请注明出处:https://doc.oinone.top/oio4/9265.html

访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验

(0)
史, 昂的头像史, 昂数式管理员
上一篇 2024年5月23日 am9:13
下一篇 2024年5月23日 am9:15

相关推荐

  • 4.1.24 框架之分库分表

    随着数据库技术的发展如分区设计、分布式数据库等,业务层的分库分表的技术终将成老一辈程序员的回忆,谈笑间扯扯蛋既羡慕又自吹地说到“现在的研发真简单,连分库分表都不需要考虑了”。竟然这样为什么要写这篇文章呢?因为现今的数据库虽能解决大部分场景的数据量问题,但涉及核心业务数据真到过亿数据后性能加速降低,能给的方案都还有一定的局限性,或者说性价比不高。相对性价比比较高的分库分表,也会是现阶段一种不错的补充。言归正传oinone的分库分表方案是基于Sharding-JDBC的整合方案,所以大家得先具备一点Sharding-JDBC的知识。 一、分表(举例) 做分库分表前,大家要有一个明确注意的点就是分表字段的选择,它是非常重要的,与业务场景非常相关。在明确了分库分表字段以后,甚至在功能上都要做一些妥协。比如分库分表字段在查询管理中做为查询条件是必须带上的,不然效率只会更低。 Step1 新建ShardingModel模型 ShardingModel模型是用于分表测试的模型,我们选定userId作为分表字段。分表字段不允许更新,所以这里更新策略设置类永不更新,并在设置了在页面修改的时候为readonly package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.boot.base.ux.annotation.field.UxWidget; import pro.shushi.pamirs.boot.base.ux.annotation.view.UxForm; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; import pro.shushi.pamirs.meta.enmu.FieldStrategyEnum; @Model.model(ShardingModel.MODEL_MODEL) @Model(displayName = "分表模型",summary="分表模型",labelFields ={"name"} ) public class ShardingModel extends AbstractDemoIdModel { public static final String MODEL_MODEL="demo.ShardingModel"; @Field(displayName = "名称") private String name; @Field(displayName = "用户id",summary = "分表字段",immutable=true/* 不可修改 **/) @UxForm.FieldWidget(@UxWidget(readonly = "scene == 'redirectUpdatePage'"/* 在编辑页面只读 **/ )) @Field.Advanced(updateStrategy = FieldStrategyEnum.NEVER) private Long userId; } 图4-1-24-1 新建ShardingModel模型 Step2 配置分表策略 配置ShardingModel模型走分库分表的数据源pamirsSharding 为pamirsSharding配置数据源以及sharding规则 a. pamirs.sharding.define用于oinone的数据库表创建用 b. pamirs.sharding.rule用于分表规则配置 pamirs: load: sessionMode: true framework: system: system-ds-key: base system-models: – base.WorkerNode data: default-ds-key: pamirs ds-map: base: base modelDsMap: "[demo.ShardingModel]": pamirsSharding #配置模型对应的库 图4-1-24-2 指定模型对应数据源 pamirs: sharding: define: data-sources: ds: pamirs pamirsSharding: pamirs #申明pamirsSharding库对应的pamirs数据源 models: "[trigger.PamirsSchedule]": tables: 0..13 "[demo.ShardingModel]": tables: 0..7 table-separator: _ rule: pamirsSharding: #配置pamirsSharding库的分库分表规则 actual-ds: – pamirs #申明pamirsSharding库对应的pamirs数据源 sharding-rules: # Configure sharding rule ,以下配置跟sharding-jdbc配置一致 – tables: demo_core_sharding_model: #demo_core_sharding_model表规则配置 actualDataNodes: pamirs.demo_core_sharding_model_${0..7} tableStrategy: standard: shardingColumn: user_id shardingAlgorithmName: table_inline shardingAlgorithms: table_inline: type: INLINE props: algorithm-expression: demo_core_sharding_model_${(Long.valueOf(user_id) % 8)} props: sql.show: true 图4-1-24-3 分库分表规则配置 Step3 配置测试入口 修改DemoMenus类增加一行代码,为测试提供入口 @UxMenu("分表模型")@UxRoute(ShardingModel.MODEL_MODEL) class ShardingModelMenu{} 图4-1-24-4 配置测试入口 Step4 重启看效果 自行尝试增删改查 观察数据库表与数据分布 图4-1-24-5 自行尝试增删改查 图4-1-24-6 观察数据库表与数据分布 二、分库分表(举例) Step1 新建ShardingModel2模型 ShardingModel2模型是用于分库分表测试的模型,我们选定userId作为分表字段。分库分表字段不允许更新,所以这里更新策略设置类永不更新,并在设置了在页面修改的时候为readonly package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.boot.base.ux.annotation.field.UxWidget; import pro.shushi.pamirs.boot.base.ux.annotation.view.UxForm; import…

    2024年5月23日
    1.3K00
  • 4.1 后端高级特性

    了解oinone的基础入门基本上可以胜任业务代码的开发,但对于构建一个完善的应用,作为技术专家或者架构需要考虑的方面还有很多,这章期望能给到您解答构建应用的所有所需知识,让您能成为那个可以带领小伙伴飞的人

    Oinone 7天入门到精通 2024年5月23日
    1.0K00
  • 4.1.21 框架之分布式消息

    消息中间件是在分布式开发中常见的一种技术手段,用于模块间的解耦、异步处理、数据最终一致等场景。 一、介绍 oinone对开源的RocketMQ进行了封装,是平台提供的一种较为简单的使用方式,并非是对RocketMQ进行的功能扩展。同时也伴随着两个非常至关重要的目的: 适配不同企业对RocketMQ的不同版本选择,不至于改上层业务代码。目前已经适配RocketMQ的开源版本和阿里云版本。 下个版本会对API进行升级支持不同类型MQ,以适配不同企业对MQ的不同要求,应对一些企业客户已经对MQ进行技术选择 对协议头进行扩展:如多租户的封装,saas模式中为了共用MQ基础资源,需要在消息头中加入必要租户信息。 二、使用准备 demo工程默认已经依赖消息,这里只是做介绍无需大家额外操作,大家可以用maven依赖树命令查看引用关系。 依赖包 增加对pamirs-connectors-event的依赖 <dependency> <groupId>pro.shushi.pamirs.framework</groupId> <artifactId>pamirs-connectors-event</artifactId> </dependency> 图4-1-21-1 分布式消息的依赖包 相关功能引入 增加模型、触发器都依赖MQ <!– 增强模型 –> <!– 增强模型 –> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-channel</artifactId> </dependency> <!– 触发器 api –> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-trigger-api</artifactId> </dependency> <!– 触发器 core –> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-trigger-core</artifactId> </dependency> 图4-1-21-2 增加模型、触发器都依赖MQ yml配置文件参考 详见4.1.1【模块之yml文件结构详解】的“pamirs.event”部分。 三、使用说明 发送消息(NotifyProducer) 概述 NotifyProducer是Pamirs Event中所有生产者的基本API,它仅仅定义了消息发送的基本行为,例如生产者自身的属性,启动和停止,当前状态,以及消息发送方法。它本身并不决定消息如何发送,而是根据具体的实现确定其功能。 目前仅实现了RocketMQProducer,你可以使用下面介绍的方法轻松使用这些功能。 使用方法 Notify注解方式 使用示例 @Component public class DemoProducer { @Notify(topic = "test", tags = "model") public DemoModel sendModel() { return new DemoModel(); } @Notify(topic = "test", tags = "dto") public DemoDTO sendDTO() { return new DemoDTO(); } } 图4-1-21-3 Notify注解方式使用示例 解释说明 使用Component注解方式注册Spring Bean。 Notify注解指定topic和tags。 topic和tags对应NotifyEvent中的topic和tags。 RocketMQProducer方法调用 使用示例 @Component public class SendRocketMQMessage { @Autowired private RocketMQProducer rocketMQProducer; /** * 发送普通消息 */ public void sendNormalMessage() { rocketMQProducer.send(new NotifyEvent("test", "model", new DemoModel())); rocketMQProducer.send(new NotifyEvent("test", "dto", new DemoDTO())); } /** * 发送有序消息 */ public void sendOrderlyMessage() { DemoModel data = new DemoModel(); data.setAge(10); rocketMQProducer.send(new NotifyEvent("test", "model", data) .setQueueSelector((queueSize, event) -> { DemoModel body = (DemoModel) event.getBody(); return body.getAge() % queueSize; })); } /** * 发送事务消息 */ public void sendTransactionMessage() { rocketMQProducer.send(new NotifyEvent("test", "model", new DemoModel()) .setIsTransaction(true) .setGroup("demoTransactionListener")); } } 图4-1-21-4 RocketMQProducer方法调用…

    2024年5月23日
    1.1K00
  • 1.5 Oinone与行业对比

    随着企业数字化转型的推进,软件公司获得了许多机会。尽管竞争日趋激烈,但由于需求旺盛,各种模式仍在不断涌现。因此,当前市场上存在各种各样的数字化转型解决方案,围绕企业的各个方面展开。每种解决方案都有其优点和缺点。本文将从定位、技术和产品等方面简单比较,帮助您从不同的视角了解Oinone的差异。 1.4.1 整体视角对比 一、与对标公司Odoo的对比 Odoo Oinone 定位 一站式全业务链管理平台:赋能企业信息化升级 一站式低代码商业支撑平台:赋能企业数字化升级 需求变化 关注单一企业的管理、流程、效率的提升 关注企业价值链的网络竞争,围绕外部协同、运营、数据、商业展开 技术更替 关注稳定、安全、功能丰富度 除了稳定、安全、功能丰富度以外,更强调需求响应速度、用户体验、系统承载极限与弹性扩展、智能化 表1-1 Oinone与对标公司Odoo的对比 二、与国内低代码或无代码公司对比 低代码或无代码公司 Oinone 定位 低代码开发工具:提供各类系统模版,基于模版快速搭建和个性化配置。但系统模版无法再升级 平台型SaaS:提供各类系统产品,产品安装后客户可以根据需求进行个性化调整,同时产品永远在线可升级 场景差异 只能支持企业内部人员使用,以完成部门级边缘系统为主,一般多为没有专业软件厂商支撑和强临时性特性 从内外部协同的商业场景出发,关注企业核心业务场景,适应【企业业务在线化后,所有的业务变化与创新都需要通过系统来触达上下游】的时代背景,以敏捷响应业务的变化与创新为目标 技术代差 单表支撑100万数据已是业内天花板 支撑单模型数据过亿,无单点瓶颈。封装互联网架构并且做到单体与分布式的灵活部署,为不同大小公司提供不同技术支撑 表1-2 Oinone与国内低代码/无代码公司对比 1.4.2 从技术角度对比 我们不会与其他无代码平台进行比较,因为它们不能解决业务复杂性的问题。相反,我们将重点介绍三种不同的低代码平台模式(如下图1-8所示)。 第一种模式是最基础的低代码平台,也被称为代码生成器。它通过预定义应用程序模板和必要的配置生成代码,简化了工程搭建并提供了一些基础逻辑。虽然在信息化时代内部流程标准化方面较为适合,但在数字化时代外部协同业务在线的情况下就不那么合适了。因为这种模式不能减少研发难度和提高效率,也无法体现敏捷迭代快速创新的优势。 第二种模式是经典的低代码平台,以元数据为基础,以模型为驱动。当无法满足需要时,通过特定方式将代码以插件的形式注入平台,作为低代码平台的内置逻辑,供设计器使用。它的优点在于降低了研发门槛,当无法满足需求时才需要编写代码。它可以实现企业内部的复杂流程和复杂逻辑,但其性能和工程管理存在局限性。性能问题使其不适合处理互联网化的在线业务,而工程管理问题则使其不适合处理快速变化的业务。这也是许多研发人员反对低代码的核心原因之一,因为研发人员变成了辅助角色,而软件工程是一门需要技术能力的学科,让没有技术能力的人主导是违反常理的。对于软件产品公司来说,产品需要迭代规划,需要多人协作,需要工程化管理。 第三种模式是oinone提出的基于互联网架构的低代码平台,它采用低无一体的设计。首先,oinone屏蔽了互联网架构带来的复杂性。其次,同样以元数据为基础,以模型为驱动,但是元数据的生成方式有两种:一种是使用无代码设计器(与经典低代码相同),另一种是通过代码来描述元数据。通过使用代码来描述元数据,可以无缝地与代码衔接,并在不改变研发习惯的情况下降低门槛、提高效率,并进行工程化管理。 最后总结来说:低无一体不仅仅是指两种模式的结合,还包括两种模式的融合应用方式。具体来说,这种融合应用方式可以分为两种情况: 当开发核心产品时,主要采用低代码开发,无代码设计器作为辅助。这种方式可以提高开发效率和代码质量,同时保证产品的快速迭代和升级。 当需要满足个性化或非产品支持的需求时,主要采用无代码设计器,低代码作为辅助。这种方式可以快速地满足客户需求,并且避免对产品的核心代码产生影响。 简单来说,低代码模式适用于产品的迭代升级,而无代码设计器则适用于满足个性化和非产品支撑的额外需求。低代码和无代码模式在整个软件生命周期中都有各自的价值,在不同场景下可以相互融合,发挥最大的优势。 图1-8 代码生成器、低代码平台与Oinone的优缺点对比 1.4.3 从产品角度对比 产品上的对比,从客户、场景满足度、再次销售三个方面来做简易的对比 一、Oinone vs 数字化软件服务商 客户 满足度 销售 Oinone 一站式商业智能软件,更高性价比、用户体验客户范围:5000万~5亿、5亿~100亿、标杆:100亿~1000亿、1000亿以上 满足企业核心业务需求,并联合伙伴一起满足企业所有需求,无需集成提供统一工作台、数据接口、底层协议,无论基于Oinone的开源框架还是增加其他应用都有很好的扩展性 支持OP+SaaS两种模式,收费方式不同:OP按买断方式进行,SaaS按效果付费跟账号数无关新的模块进行二次销售 数字化软件服务商 针对成熟的大型企业需投入巨大资源和成本客户范围:100亿~1000亿、1000亿以上 满足企业部分需求,无法输出技术标准,无法解决多供应商一起开发的问题,只能通过集成实现对接 OP模式进行销售,通过设置权限来进行来实现二次销售或无法进行二次销售 表1-3 Oinone vs 数字化软件服务商 二、Oinone vs 低代码或无代码行业 客户 满足度 销售 Oinone 一站式商业智能软件客户范围:5000万~5亿、5亿~100亿、标杆:100亿~1000亿、1000亿以上 从外部商业场景出发,强业务场景驱动,符合企业从信息化管理到业务创新的数字化转变的趋势。提供统一工作台、数据接口、底层协议,无论基于oinone的开源框架还是增加其他应用都有很好的扩展性 支持OP+SaaS两种模式,收费方式不同:OP按买断方式进行,SaaS按效果付费跟账号数无关新的模块进行二次销售 低代码或无代码公司 针对小微企业内部信息化管理诉求,以表单流程为主客户范围:5亿以下 满足企业部门级信息化的适应性需求,无法满足企业核心业务管理与业务创新诉求 按应用模块进行收费,新的模块进行二次销售 表1-4 Oinone vs 低代码或无代码行业 三、Oinone vs 国外对标公司Odoo 客户 满足度 销售 Oinone 一站式商业智能软件客户范围:5000万~5亿、5亿~100亿、标杆:100亿~1000亿、1000亿以上 从外部商业场景出发,强业务场景驱动,符合企业从信息化管理到业务创新的数字化转变的趋势。基线产品覆盖:采购、营销、服务、销售、交易等企业商业领域。主要涉及行业:零售品牌。其他领域或行业靠合作伙伴共建方式进行 支持OP+SaaS两种模式,收费方式不同:OP按买断方式进行,SaaS按效果付费跟账号数无关新的模块进行二次销售 Odoo 一站式企业管理软件客户范围:5000万~5亿、5亿~100亿、标杆:100亿~1000亿、1000亿以上 从企业内部管理需求出发,逐渐拥有互联网相关应用组件,但还是属于强内部管理、弱外部场景。基线产品覆盖:业务财务一体化、人财务、进销存。主要涉及行业:建造业。其他领域或行业靠合作伙伴共建方式进行 支持OP+SaaS两种模式,收费方式相同:按用户数+应用模块进行收费新的模块进行二次销售 表1-5 Oinone vs 国外对标公司Odoo

    2024年5月23日
    2.0K20
  • 3.5.6 DSL配置大全(略)

    因为默认视图很难满足客户的个性化需求,所以日常开发中view的配置是避免不了的。本系列篇是比较全面地介绍View配置的各个方面涉及:视图、字段、动作、布局等

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

Leave a Reply

登录后才能评论