Excel导入导出模板翻译

张博昊 • 2024年12月5日 pm5:56 • 后端 • 阅读 814

导出翻译项

与翻译的导出全部翻译项类似，只是该操作目前没有加入到页面交互中，需要通过工具发起后端服务请求，拿到导入导出翻译Excel模版，添加模版翻译项。（查看路径：文件--导出任务）

mutation {
  excelExportTaskMutation {
    createExportTask(
      data: {
        workbookDefinition: {
          model: "file.ExcelWorkbookDefinition"
          name: "excelLocationTemplate"
        }
      }
    ) {
      name
    }
  }
}

variables:
{
  "path": "/file",
  "lang": "en-US"
}

参数说明：（不在以下说明范围内的参数无需修改）

variables.lang参数：用于指定翻译项的目标语言编码，与【资源】-【语言】中的编码一致。

导入翻译项

mutation {
  excelImportTaskMutation {
    createImportTask(
      data: {
        workbookDefinition: {
          model: "file.ExcelWorkbookDefinition"
          name: "excelLocationTemplate"
        }
        file: {
          url: "翻译项URL链接"
        }
      }
    ) {
      name
    }
  }
}

variables:
{
  "path": "/file"
}

参数说明：

将翻译项URL链接改为实际可访问的文件链接即可，可通过页面中任意文件上传的组件获取。

Oinone社区作者：张博昊原创文章，如若转载，请注明出处：https://doc.oinone.top/backend/19781.html

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

张博昊数式管理员

0 0

正式版发布：Oinone 5.3.0 版本新增微流设计器，邀您体验

上一篇 2024年12月5日 pm5:41

两个环境使用同一套用户，但是隔离用户角色的解决方案

下一篇 2024年12月5日 pm7:27

后端

工作流引入流程概览与流程监控

流程概览依赖说明使用流程概览功能前，需要在项目中引入 pamirs-workflow-datavi-core 依赖： <dependency> <groupId>pro.shushi.pamirs.workflow</groupId> <artifactId>pamirs-workflow-datavi-core</artifactId> </dependency> 警告：在 oinone 平台启用「流程概览」能力时，应用启动模块一旦引入 pamirs-workflow-api/core，必须同时引入 pamirs-workflow-datavi-api/core。在多启动模块架构下，严禁出现仅部分启动模块引入 pamirs-workflow-core 而未引入 pamirs-workflow-datavi-core 的情况，否则将导致流程概览相关元数据计算异常，出现删表等情况。流程概览配置项流程概览页面内置缓存机制，可通过配置项调整缓存刷新周期及图表展示的数据条数： pamirs: workflow: dashboard: cache-time: 10 # 流程概览缓存刷新时间（单位：分钟），默认 10 分钟 page-size: 10 # 流程运行分析中 4 个图表的展示数量，默认查询前 10 条数据统计指标说明引入 pamirs-workflow-datavi-core 依赖后，系统会按照以下规则进行数据同步：当日数据同步：每小时同步一次当日数据；昨日数据同步：次日凌晨同步前一日数据。由于在引入依赖后才会开始执行数据同步，统计指标页提供了「同步」按钮，可用于对历史数据进行补采。即使不执行历史同步，也不会影响核心业务流程，仅会影响统计数据和图表的展示效果。统计指标数据主要用于支撑流程概览和流程监控中的统计图表展示；为数据分析与可视化提供基础数据。上述统计数据对工作流的审批、流转等核心业务无任何影响。如有需要，也可以基于流程监控的数据，配合数据可视化设计器，自定义构建符合业务需求的展示页面。

夜神月
2025年11月17日
76000
后端

技术精要：数据导出与固化实用指南

数据被认为是企业发展和决策的重要资产。随着业务的不断发展和数据量的不断增加，企业通常需要将数据从不同的源头导出，并将其固化到产品中，以便进行进一步的分析、处理和利用。数据导出与固化的过程涉及到数据的提取、清洗、整合和存储，是确保数据长期有效性和可用性的关键步骤。了解数据导出与固化的流程和方法对于企业具有重要意义。通过有效的数据导出和固化，企业可以更好地管理和利用数据资源，提升决策的准确性和效率，实现业务的持续发展和创新。本次讨论将重点探讨数据导出与固化的流程和关键步骤，帮助参与者深入了解如何将数据从导出到产品中，为企业数据管理和应用提供有力支持。 1. 数据导出与固化：将数据从导出到产品中的流程 1.1. pom依赖： <dependency> <groupId>pro.shushi.pamirs.metadata.manager</groupId> <artifactId>pamirs-metadata-manager</artifactId> </dependency> 1.2 将第⼆步下载后的⽂件放⼊项⽬中（注意⽂件放置的位置）。放置⼯程的resources 下⾯。例如： 1.3 项⽬启动过程中，将⽂件中的数据导⼊(通常放在core模型的init包下⾯)。⽰例代码： package pro.shushi.pamirs.sys.setting.enmu; import com.google.common.collect.Lists; import org.apache.commons.collections4.CollectionUtils; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.context.ApplicationContext; import org.springframework.stereotype.Component; import pro.shushi.pamirs.boot.common.api.command.AppLifecycleCom mand; import pro.shushi.pamirs.boot.common.api.init.LifecycleCompleted AllInit; import pro.shushi.pamirs.boot.common.extend.MetaDataEditor; import pro.shushi.pamirs.core.common.InitializationUtil; import pro.shushi.pamirs.meta.annotation.fun.extern.Slf4j; import pro.shushi.pamirs.meta.api.dto.meta.Meta; import pro.shushi.pamirs.meta.domain.module.ModuleDefinition; import pro.shushi.pamirs.metadata.manager.core.helper.DesignerIn stallHelper; import pro.shushi.pamirs.metadata.manager.core.helper.WidgetInst allHelper; import java.util.List; import java.util.Map; @Slf4j @Component public class DemoAppMetaInstall implements MetaDataEditor, LifecycleCompletedAllInit { @Autowired private ApplicationContext applicationContext; @Override public void edit(AppLifecycleCommand command, Map<String, Meta> metaMap) { if (!doImport()) { return; } log.info("[设计器业务元数据导⼊]"); InitializationUtil bizInitializationUtil = InitializationUtil.get(metaMap, DemoModule.MODULE_MODULE/ ***改成⾃⼰的Module*/, DemoModule.MODULE_NAME/***改成⾃⼰的 Module*/); DesignerInstallHelper.mateInitialization(bizInitializatio nUtil, "install/meta.json"); log.info("[⾃定义组件元数据导⼊]"); // 写法1: 将组件元数据导⼊到⻚⾯设计器. 只有在安装设计器的服务中执⾏才有效果 WidgetInstallHelper.mateInitialization(metaMap, "install/widget.json"); // 写法2: 与写法1相同效果 InitializationUtil uiInitializationUtil = InitializationUtil.get(metaMap, "ui_designer", "uiDesigner"); if (uiInitializationUtil != null) { DesignerInstallHelper.mateInitialization(uiInitialization Util, "install/widget.json"); } // 写法3: 业务⼯程和设计器分布式部署,且希望通过业务⼯程导⼊⾃定义组件元数据. 业务模块需要依赖⻚⾯设计器模块,然后指定业务模块导⼊ DesignerInstallHelper.mateInitialization(bizInitializatio nUtil, "install/widget.json"); } @Override public void process(AppLifecycleCommand command, Map<String, ModuleDefinition> runModuleMap) { if (!doImport()) { return; } log.info("[设计器业务数据导⼊]"); // ⽀持远程调⽤,但是执⾏的⽣命周期必须是 LifecycleCompletedAllInit或之后. 本地如果安装了设计器,则没有要求 DesignerInstallHelper.bizInitialization("install/ meta.json"); log.info("[⾃定义组件业务数据导⼊]"); // 当开发环境和导⼊环境的⽂件服务不互通时, 可通过指定js和 css的⽂件压缩包,⾃动上传到导⼊环境,并替换导⼊组件数据中的⽂件url // WidgetInstallHelper.bizInitialization("install/ widget.json", "install/widget.zip"); WidgetInstallHelper.bizInitialization("install/ widget.json"); return; } private boolean doImport() { // ⾃定义导⼊判断. 避免⽤于设计的开发环境执⾏导⼊逻辑 String[] envs = applicationContext.getEnvironment().getActiveProfiles(); List<String> envList = Lists.newArrayList(envs); return…

数式-海波
2024年2月27日
1.8K002
代码实践

如何选择适合的模型类型？

介绍通过Oinone 7天从入门到精通的模型的类型章节我们可以知道模型有抽象模型、存储模型、代理模型、传输模型这四种。但是在在定义模型的时候我们可能不知道该如何选择类型，下面结合业务场景为大家讲解几种模型的典型使用场景。抽象模型抽象模型往往是提供公共能力和字段的模型，它本身不会直接用于构建协议和基础设施（如表结构等）。场景：猫、鸟都继承自动物这个抽象模型 package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; import pro.shushi.pamirs.meta.annotation.sys.Base; import pro.shushi.pamirs.meta.base.IdModel; import pro.shushi.pamirs.meta.enmu.ModelTypeEnum; @Base @Model.model(AbstractAnimal.MODEL_MODEL) @Model.Advanced(type = ModelTypeEnum.ABSTRACT) @Model(displayName = "动物") public abstract class AbstractAnimal extends IdModel { public static final String MODEL_MODEL = "demo.AbstractAnimal"; @Field.String @Field(displayName = "名称") private String name; @Field.String @Field(displayName = "颜色") private String color; } package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; @Model.model(Cat.MODEL_MODEL) @Model(displayName = "猫") public class Cat extends AbstractAnimal { private static final long serialVersionUID = -5104390780952634397L; public static final String MODEL_MODEL = "demo.Cat"; @Field.Integer @Field(displayName = "尾巴长度") private Integer tailLength; } package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; @Model.model(Bird.MODEL_MODEL) @Model(displayName = "鸟") public class Bird extends AbstractAnimal { private static final long serialVersionUID = -5144390780952634397L; public static final String MODEL_MODEL = "demo.Bird"; @Field.Integer @Field(displayName = "翼展宽度") private Integer wingSpanWidth; } 存储模型存储模型用于定义数据表结构和数据的增删改查（数据管理器）功能，是直接与连接器进行交互的数据容器。场景：存储模型对应传统开发模式中的数据表，上面例子中的Cat和Birdd都属于传输模型，由于模型定义的注解@Model.Advanced(type = ModelTypeEnum.STORE)默认值就是存储模型，所以一般不用手动指定代理模型代理模型是用于代理存储模型的数据管理器能力，同时又可以扩展出非存储数据信息的交互功能的模型。场景一：隔离数据权限场景二：增强列表的搜索项场景三：导入导出的时候增加其他特殊信息场景四：重写下拉组件的查询逻辑做数据过滤传输模型传输模型不会在数据库生成的表，只是作为数据的传输使用，跟传统开发模式中的DTO有一点相似。场景一：批量处理数据场景二：处理一些跟数据表无关的操作，如：清理指定业务的缓存、查看一些系统监控信息，可以根据业务信息建立对应的传输模型，在传输模型上创建action动作场景三：通过传输模型完成复杂页面数据传输

nation
2024年4月7日
1.3K002
后端

后端代码规范

前言虽然oinone框架减少了很多的代码，但是低代码部分的代码质量也需要高度关注，不管是写的代码bug多，或者说被吐槽代码不行，还是说写的代码经常被重构，核心点还是没有代码规范的意识和技巧，下面摘录了一些常见的规范要求，去提高后端的代码质量，代码质量提高后，自然效率也会提升。常见代码规范 **1、规范命名** 命名是写代码中最频繁的操作，比如类、属性、方法、参数等。好的名字应当能遵循以下几点： **见名知意** 比如需要定义一个变量需要来计数 int i = 0; 名称 i 没有任何的实际意义，没有体现出数量的意思，所以我们应当指明数量的名称 int count = 0; **能够读的出来** 如下代码： private String sfzh; private String dhhm; 这些变量的名称，根本读不出来，更别说实际意义了。所以我们可以使用正确的可以读出来的英文来命名 private String idCardNo; private String phone; **2、规范代码格式** 好的代码格式能够让人感觉看起来代码更加舒适。好的代码格式应当遵守以下几点：合适的空格代码对齐，比如大括号要对齐及时换行，一行不要写太多代码好在现在开发工具支持一键格式化，可以帮助美化代码格式，大家统一使用idea的规范即可。 **3、写好代码注释** 在《代码整洁之道》这本书中作者提到了一个观点，注释的恰当用法是用来弥补我们在用代码表达意图时的失败。换句话说，当无法通过读代码来了解代码所表达的意思的时候，就需要用注释来说明。书的作者之所以这么说，是因为作者觉得随着时间的推移，代码可能会变动，如果不及时更新注释，那么注释就容易产生误导，偏离代码的实际意义。而不及时更新注释的原因是，程序员不喜欢写注释。😒 但是这不意味着可以不写注释，当通过代码如果无法表达意思的时候，就需要注释，比如如下代码： for (Integer id : ids) { if (id == 0) { continue; } //做其他事 } 为什么 id == 0 需要跳过，代码是无法看出来了，就需要注释了。好的注释应当满足一下几点：解释代码的意图，说明为什么这么写，用来做什么对参数和返回值注释，入参代表什么，出参代表什么有警示作用，比如说入参不能为空，或者代码是不是有坑当代码还未完成时可以使用 todo 注释来标记代码review发现漏洞时可以使用 fixme 注释来标记 **4、try catch 内部代码抽成一个方法** try catch代码有时会干扰我们阅读核心的代码逻辑，这时就可以把try catch内部主逻辑抽离成一个单独的方法如下图是Eureka服务端源码中服务下线的实现中的一段代码整个方法非常长，try中代码是真正的服务下线的代码实现，finally可以保证读锁最终一定可以释放。所以这段代码其实就可以对核心的逻辑进行抽取。 protected boolean internalCancel(String appName, String id, boolean isReplication) { try { read.lock(); doInternalCancel(appName, id, isReplication); } finally { read.unlock(); } // 剩余代码 } private boolean doInternalCancel(String appName, String id, boolean isReplication) { //真正处理下线的逻辑 } **5、方法别太长** 方法别太长就是字面的意思。一旦代码太长，给人的第一眼感觉就很复杂，让人不想读下去；同时方法太长的代码可能读起来容易让人摸不着头脑，不知道哪一些代码是同一个业务的功能。比如代码中有那种2000+行大类，各种if else判断，光理清代码思路就需要用很久时间。🤷🏻‍♀️ 所以一旦方法过长，可以尝试将相同业务功能的代码单独抽取一个方法，最后在主方法中调用即可。 **6、抽取重复代码** 当一份代码重复出现在程序的多处地方，就会造成程序又臭又长，当这份代码的结构要修改时，每一处出现这份代码的地方都得修改，导致程序的扩展性很差。所以一般遇到这种情况，可以抽取成一个工具类，还可以抽成一个公共的父类。 **7、多用return** 在有时我们平时写代码的情况可能会出现if条件套if的情况，当if条件过多的时候可能会出现如下情况： if (条件1) { if (条件2) { if (条件3) { if (条件4) { if (条件5) { System.out.println("11111"); } } } } } 面对这种情况，可以换种思路，使用return来优化 if (!条件1) { return; } if (!条件2) { return; } if (!条件3) { return; } if (!条件4) { return; } if (!条件5) { return; } System.out.println("11111"); 这样优化就感觉看起来更加直观 **8、if条件表达式不要太复杂**…

冯, 天宇
2024年12月11日
2.4K003
后端

自定义用户中心菜单

使用扩展点实现用户中心菜单替换 1. 工程中引起pamirs-user-api <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-user-api</artifactId> </dependency> 2. 实现TopBarUserBlockAction的后置扩展实现HookAfter后置扩展接口 @Hook(model = {TopBarUserBlock.MODEL_MODEL}, fun = {"construct"})添加Hook注解注明是TopBarUserBlock模型的construct函数的后置扩展。增加用户中心菜单 @Component @Order(1) @SPI.Service public class MyTopBarActionExt implements TopBarActionExtendApi { public void edit(List<TopBarAction> list) { list.add(new TopBarAction("top_demo", "top.Teacher", "uiView9a0caf1d574a42c9847a057a0c4a4ad1", ActionTypeEnum.VIEW, 1) .setDisplayName("商品管理") .setIcon("oinone-gongzuotai") ); } } 实现效果替换原有的用户中心菜单替换原有的菜单跳转 @Component public class DemoTopBarUserBlockDataHookAfter implements HookAfter { @Override @Hook(model = {TopBarUserBlock.MODEL_MODEL}, fun = {"construct"}) public Object run(Function function, Object ret) { if (ret == null) { return null; } TopBarUserBlock result = null; if (ret instanceof Object[]) { Object[] rets = (Object[]) ((Object[]) ret); if (rets.length == 1) { result = (TopBarUserBlock) rets[0]; //例：替换用户中心：修改密码菜单 //使用name和model查询出模型的ViewAction替换修改密码ViewAction ViewAction demoViewAction = PamirsSession.getContext().getExtendCache(ActionCacheApi.class).get(Dog.MODEL_MODEL, "changePassword"); //设置菜单的icon Map<String, Object> attributes = Optional.ofNullable(demoViewAction.getAttributes()).orElse(new HashMap<>()); attributes.put("icon", "oinone-xiugaimima"); demoViewAction.setAttributes(attributes); //UserViewAction第0个是修改密码ViewAction，使用自定义的ViewAction就可以实现替换 result.getUserViewAction().set(0, demoViewAction); } } else { result = (TopBarUserBlock) ret; } return result; } } 使用@UxRouteButton方式新增ViewAction，更多新增Action方式详见：Action的类型 @Model.model(Dog.MODEL_MODEL) @Component @UxRouteButton( action = @UxAction(name = "changePassword", displayName = "修改密码"), value = @UxRoute(model = Dog.MODEL_MODEL, openType = ActionTargetEnum.DIALOG)) public class DogAction { } 替换原有的个人设置头像跳转修改点击头像绑定的跳转逻辑 @Order(10) @Component @SPI.Service public class DemoTopBarUserBlockDataApi implements TopBarUserBlockDataApi { @Override public TopBarUserBlock extendData(TopBarUserBlock data) { //例如增加一个菜单, PamirsDemo.MODEL_MODEL: 模型。 MenuuiMenu31f22466735a4abe8e0544b428ed88ac：viewAction的name。 Action demoViewAction =…

yexiu
2024年7月4日
1.4K000

登录后才能评论

shao 2024年11月25日

支持其他的国家的语言，需要在资源里面创建，如果有其他的疑问，也可以群内联系我们哈

评论于 6.4 国际化之多语言
xiao3 2024年11月25日

只支持英语吗？如何添加其他语种？

评论于 6.4 国际化之多语言
psyy 2024年8月21日

1.4 Oinone对软件特性的思考，技术原理一段，几余（几->冗） 1.4 Oinone对软件特性的思考，协同演进一段，新特生（生->性）

评论于 1.4 Oinone对软件特性的思考
望闲 2024年6月21日

感谢反馈，已修正

评论于 1.5 Oinone与行业对比
xinf 2024年6月14日

bug反馈：采用无一体设计 -> 采用低无一体设计

评论于 1.5 Oinone与行业对比

Excel导入导出模板翻译

导出翻译项

导入翻译项

相关推荐

工作流引入流程概览与流程监控

技术精要：数据导出与固化实用指南

如何选择适合的模型类型？

后端代码规范

自定义用户中心菜单

Leave a Reply