「前端」 获取当前用户信息以及语言

相关推荐

• 前端

  前端自定义左树右表中的树

  在 oinone 平台中，提供了默认的左树右表的视图，用户可以通过界面设计器配置，默认的树视图不一定满足所有需求，尤其当需要自定义功能或复杂的交互时，我们可以通过自定义视图来实现更灵活的展现。 本文将带你一步步了解如何自定义左树右表视图中的树组件。 自定义树视图 1. 使用界面设计器配置视图 首先，我们需要通过界面设计器生成基础的左树右表视图。界面设计器允许用户根据不同需求进行拖拽配置，快速创建可视化界面。 配置完视图之后，我们可以重写左侧的树组件。Oinone 的默认树组件是 TableSearchTreeWidget，通过自定义的方式，我们可以实现更高级的功能。 2. 重写 TableSearchTreeWidget import { BaseElementWidget, SPI, TableSearchTreeWidget, ViewType } from '@kunlun/dependencies'; import CustomTableSearchTree from './CustomTableSearchTree.vue'; @SPI.ClassFactory( BaseElementWidget.Token({ viewType: [ViewType.Table, ViewType.Form], widget: 'tree', model: 'resource.k2.Model0000000100' // 改成自己的模型 }) ) export class CustomTableSearchTreeWidget extends TableSearchTreeWidget { public initialize(props) { super.initialize(props); this.setComponent(CustomTableSearchTree); return this; } } 3. 定义 Vue 树组件 接下来，我们来实现 CustomTableSearchTree.vue 组件。这个组件将处理树的数据加载、节点选中等逻辑。你可以根据项目的需要修改其中的交互逻辑或 UI 设计。 <template> <a-tree :load-data="onLoadData" :tree-data="treeData" @select="onSelected" /> </template> <script lang="ts"> import { OioTreeNode, TreeUtils } from '@kunlun/dependencies'; import { computed, defineComponent } from 'vue'; export default defineComponent({ props: { rootNode: { type: Object }, loadData: { type: Function, required: true }, onSelected: { type: Function, required: true } }, setup(props) { // // 计算树的数据源，使用 TreeUtils 处理 const treeData = computed(() => { return TreeUtils.fillLoadMoreAction([…(props.rootNode?.children || [])]); }); // 异步加载子节点 const onLoadData = async (node) => { return await props.loadData(node.dataRef); }; // 处理节点选中事件 const onSelected = ( selectedKeys: string[], e: { nativeEvent: PointerEvent; node: { dataRef: OioTreeNode }; selected: boolean } ) => { props.onSelected?.(e.node.dataRef, e.selected); }; return { treeData, onLoadData, onSelected }; } }); </script> 4. 自定义…

  汤乾华

  2024年10月21日

  2.6K000
• 组件

  oio-drawer抽屉

  屏幕边缘滑出的浮层面板。 何时使用 抽屉从父窗体边缘滑入，覆盖住部分父窗体内容。用户在抽屉内操作时不必离开当前任务，操作完成后，可以平滑地回到原任务。 当需要一个附加的面板来控制父窗体内容，这个面板在需要时呼出。比如，控制界面展示样式，往界面中添加内容。 当需要在当前任务流中插入临时任务，创建或预览附加内容。比如展示协议条款，创建子对象。 API 参数 说明 类型 默认值 版本 class 对话框外层容器的类名 string – closable 是否显示左上角的关闭按钮 boolean true closeIcon 自定义关闭图标 VNode | slot destroyOnClose 关闭时销毁 Drawer 里的子元素 boolean false footer 抽屉的页脚 VNode | slot – getTriggerContainer 指定 Drawer 挂载的 HTML 节点 HTMLElement | () => HTMLElement | Selectors ‘body’ height 高度, 在 placement 为 top 或 bottom 时使用 string | number keyboard 是否支持键盘 esc 关闭 boolean true mask 是否展示遮罩 Boolean true maskClosable 点击蒙层是否允许关闭 boolean true placement 抽屉的方向 ‘top’ | ‘right’ | ‘bottom’ | ‘left’ ‘right’ style 可用于设置 Drawer 最外层容器的样式，和 drawerStyle 的区别是作用节点包括 mask CSSProperties – title 标题 string | slot – visible(v-model:visible) Drawer 是否可见 boolean – width 宽度 string | number 378 zIndex 设置 Drawer 的 z-index Number 1000 cancelCallback 点击遮罩层或右上角叉或取消按钮的回调, return true则关闭弹窗 function(e) enterCallback 点击确定回调 function(e)

  汤乾华

  2023年12月18日

  1.1K000
• 低无一体

  列表页内上下文无关的动作如何添加自定义上下文

  场景 在界面设计器，可以配置当前列表页从上个页面带的上下文参数，现在需要传递这个上下文到下个页面，设计器没有配置入口，我们可以通过自定义改动作来解决 示例代码 import { ActionType, ActionWidget, RouterViewActionWidget, SPI, ViewActionTarget } from '@kunlun/dependencies'; @SPI.ClassFactory( ActionWidget.Token({ actionType: [ActionType.View], target: [ViewActionTarget.Router], // 模型编码 model: 'module.model', // 动作名称 name: 'actionName' }) ) export class DemoRouterViewActionWidget extends RouterViewActionWidget { protected async clickAction(): Promise<void> { // initialContext内是上个页面传来的上下文，手动将值传递到下个页面的上下文 // 这里假设需要传递的字段名为type this.action.context = { type: this.initialContext.type }; return super.clickAction(); } }

  nation

  2024年8月20日

  1.6K000
• 低无一体

  表单页如何在服务端动作点击后让整个表单都处于loading状态

  介绍 在业务场景中，有时候由于提交的数据很多，导致服务端动作耗时较长，为了保证这个过程中表单内的字段不再能被编辑，我们可以通过自定义能力将整个表单区域处于loading状态 自定义动作组件代码 import { ActionType, ActionWidget, BaseElementViewWidget, BaseView, ClickResult, ServerActionWidget, SPI, Widget } from '@kunlun/dependencies'; @SPI.ClassFactory(ActionWidget.Token({ actionType: ActionType.Server })) class LoadingServerActionWidget extends ServerActionWidget { protected async clickAction(): Promise<ClickResult> { const baseView = Widget.select(this.rootHandle) as unknown as BaseView; if (!baseView) { return super.clickAction(); } const baseViewWidget = baseView.getChildrenInstance().find((a) => a instanceof BaseElementViewWidget) as unknown as BaseElementViewWidget; if (!baseViewWidget) { return super.clickAction(); } return new Promise((resolve, reject) => { try { baseViewWidget.load(async () => { const res = await super.clickAction(); resolve(res); }); } catch (e) { reject(false); } }); } } 本案例知识点 BaseElementWidget提供了load方法将继承了该class的元素渲染的区域做整体loading交互，等入参的函数处理完成后恢复正常状态，其实所有继承了ActionWidget的组件也提供了这个能力让按钮在执行函数中的时候处于loading状态， 每个组件都有一个全局唯一的handle值，所在根视图的rootHandle,组件可以用this.rootHandle通过Widget.Select方法查找到所在的根视图组件，从视图的实例化子元素里可以查找到具体的业务类型视图组件，如详情页的DetailWidget、表单页的FormWidget、表格页的TableWidget，拿到这些实例后就可以操作里面的属性和方法了

  nation

  2024年5月29日

  1.3K000
• 后端

  后端代码规范

  前言 虽然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.7K003