Oinone FAQ

问题现象 密码输入正确登录仍失败，后端有报错日志，会出现关键字：InvalidKeyException: Illegal key size 密码解密失败原因排查 异常日志 2022-07-15 13:58:58.439 INFO 17064 — [0.0-8090-exec-5] p.s.pamirs.user.api.utils.AES256Utils : java.security.InvalidKeyException: Illegal key size at javax.crypto.Cipher.checkCryptoPerm(Cipher.java:1039) ~[na:1.8.0_121] at javax.crypto.Cipher.implInit(Cipher.java:805) ~[na:1.8.0_121] at javax.crypto.Cipher.chooseProvider(Cipher.java:864) ~[na:1.8.0_121] at javax.crypto.Cipher.init(Cipher.java:1396) ~[na:1.8.0_121] at javax.crypto.Cipher.init(Cipher.java:1327) ~[na:1.8.0_121] at pro.shushi.pamirs.user.api.utils.AES256Utils.decrypt(AES256Utils.java:93) ~[pamirs-user-api-3.0.1-20220715.032940-5.jar:na] at pro.shushi.pamirs.user.api.crypto.DecryptAspect.decryptObj(DecryptAspect.java:81) [pamirs-user-api-3.0.1-20220715.032940-5.jar:na] at pro.shushi.pamirs.user.api.crypto.DecryptAspect.decryptData(DecryptAspect.java:62) [pamirs-user-api-3.0.1-20220715.032940-5.jar:na] at pro.shushi.pamirs.user.api.crypto.DecryptAspect.decrypt(DecryptAspect.java:44) [pamirs-user-api-3.0.1-20220715.032940-5.jar:na] 异常原因：如果密钥大于128, 会抛出java.security.InvalidKeyException: Illegal key size 异常. 因为密钥长度是受限制的, java运行时环境读到的是受限的policy文件. 文件位于${java_home}/jre/lib/security, 这种限制是因为美国对软件出口的控制.参考资料：https://www.cnblogs.com/jinloooong/p/10619353.html 解法办法 1、请检查jdk版本是否高于1.8_221以上。 2、如无法升级jdk版本的环境下，下载JCE无限制权限策略文件。请点击下载 jce_policy-8.zip 并按照如下步骤进行操作： 解压jce_policy-8.zip，得到两个文件US_export_policy.jar和local_policy.jar 如果安装了JRE，将两个jar文件放到%JRE_HOME%\lib\security目录下覆盖原来的文件 如果安装了JDK，将两个jar文件放到%JDK_HOME%\jre\lib\security目录下覆盖原来文件

如何获取当前页面中的全部可用字段？ 在Class Component(ts)中使用以下代码获取当前设计组件实例 “` tsimport { WidgetInstance } from &#039;@kunlun/ui-designer-dependencies&#039;; @Widget.Reactive()@Widget.Inject()protected currentInstance: WidgetInstance | undefined;“` PS：这里使用了@kunlun/ui-designer-dependencies依赖包中的类型定义，但没有使用函数，因此这个导入是可以正常执行的。 在Vue组件中使用以下代码获取可选字段列表 “` tsimport { WidgetInstance } from &#039;@kunlun/ui-designer-dependencies&#039;; // props add currentInstance defineprops: { currentInstance: { type: Object as PropType<WidgetInstance> }} // setup using currentInstance get fieldsconst fields = computed(() => { return Array.from(props.currentInstance?.root?.fieldCollection.values() || []).map((v) => { return { label: v.element?.widgetData?.displayName, value: v.element?.name }; });});“` PS：这里的v.element?.widgetData?.displayName获取的是字段的元数据显示名称，如果需要获取字段输入的标题可以使用v.element?.properties?.label。 为什么需要选择当前页面中的字段？ 页面在发起请求时，会根据当前视图中的字段查询最小结果集，不在页面中的字段无法被正确获取。可以将用到的字段拖放至视图中，并使用【隐藏】属性进行隐藏即可。 列内容超过当前表格行高该怎么办？ 在界面设计器中选中表格组件，可以为表格设置指定的行高。 在界面设计器的属性面板组件中，如何获取当前字段所在模型的模型编码？ “` tsinterface InternalMetadata { model?: string;} @Widget.Reactive()protected get currentModel(): string | undefined { return (this.formData._metadata as InternalMetadata)?.model;}“` 在界面设计器的属性面板组件中，如何获取关联关系字段的关联模型的模型编码？ “` tsinterface InternalMetadata { modelReferences?: { model?: string; };} @Widget.Reactive()protected get referenceModel(): string | undefined { return (this.formData._metadata as InternalMetadata)?.modelReferences?.model;}“` 如何理解关联关系字段中的【透出字段(选项字段列表)】属性？ 正如我们现在已知的，页面发起查询请求时，将根据页面中的元数据获取最小结果集，不在页面中的字段并不包含在结果集中。这样虽然使得我们可以最小化的控制结果集的大小。 但对于关联关系类型的字段来说，我们也面临了一个无法回避的问题：对于【表格】、【表单】等这些组件，我们可以通过拖放字段的方式直接将字段展示在页面中，因此对于这些可被设计的组件而言无需其他过多的配置即可正常使用。但对于【下拉单选】、【下拉多选】等这些组件而言，我们无法在页面中直接定义关联关系字段的元数据。 我们在解决这一问题上也同样做了很多，比如当你在【下拉单选】中设置【选项标题】时，选项标题中的字段会被自动透出到页面中，在发起请求时也就能正常获取这些字段了。 特殊的是，如果某些字段只是在逻辑上被使用的，但又不能将其通过【选项标题】展示给用户的时候，我们必须使用一个属性来定义这些字段，使得我们的业务逻辑可以正常运行。因此，我们设计了【透出字段】来解决这一问题。 为什么在属性面板中的【选项字段列表】是【透出字段】呢？ 正如我们在业务开发过程中，服务端的模型定义的显示名称和在界面设计器中的字段标题可以是不一致的。由于服务端模型定义的字段API名称为optionFields，其中文直译是【选项字段列表】，但我们在产品设计时，希望这一属性可以被用户理解，因此在页面上展示的时候使用了【透出字段】作为标题呈现给用户。 在界面设计器中如何配置【透出字段(选项字段列表)】？ optionFields在配置时使用的是字段的API名称，在关联关系属性定义时，允许使用.分隔的方式定义关联关系字段的关联属性。 如：[‘code’, ‘name’, ‘user.code’, ‘user.name’]。其中user字段为多对一(M2O)的关联关系字段，其中有两个字段code和name。 与之对应的GQL响应结构为： query { xxxxxxQuery { queryPage(xxxxxx) { content { code name user { code name } } } } } 在界面设计器的属性面板组件中，如何通过代码方式设置【透出字段(选项字段列表)】？ @Widget.Method() public setOptionFields(optionFields: string[]) { this.formData.optionFields = optionFields; } 如何在字段中使用mountedCallChaining提供mountedProcess方法？ @Widget.Reactive() @Widget.Inject() protected mountedCallChaining: CallChaining | undefined; protected mountedProcess() {} protected mounted() { super.mounted(); this.mountedCallChaining?.hook(this.path, async () => { await this.mountedProcess(); }); } protected unmounted() { super.unmounted(); this.mountedCallChaining?.unhook(this.path); }

1.Oinone能做什么？ Oinone 是一款专注解决复杂业务场景的开源低代码应用平台，旨在提供所见即所得的快速可视化搭建应用功能，并打造企业专属的低代码平台。 提升交付效率，缩短交付周期； 减少人力投入，解决技术人才招聘难的难题； 减少接联调，减少重复建设，解决质量管控难题； 一键轻松安装，应用全生命周期管理，解决应用管理难题； 2.为什么要用Oinone？ 用Oinone低代码平台可以帮助企业应对竞争变化、适应业务变化、满足技术需求、提高研发效率，并且低代码平台已经成为企业数字化转型的核心工具之一。 企业竞争变化，从单一企业变相兼职链的网络竞争; 业务变化，从信息化时代，内部/管理/流程、结果，变向数字时代，外部/商业，运营; 技术更替，从主球稳定，安全，功能丰富可配置到系统性能极限承载能力与弹性扩容/随需而变，需求响应速度、智能;化、实时分析，数据与业务的联动，用户体验，B端的业务需求C端的体验; 对研发人员的需求越来越大，同时要求越来越高。低代码平台是提升研发效率，降低研发成本核心手段; 低代码的地位已经从辅助走向核心; 3.Oinone 和其他的无代码平台相比优势是什么 既支持无代码的拖拉拽，还能通过研发框架支持自主工程研发; 低代码和无代码在贯彻了整个软件的生命周期，在不同场景发挥不同价值; 可基于软件工程理论，进行科学管理； 不改变研发习惯，主流开源技术栈，无抵触心理 4.我是软件公司，用不用Oinone？ 软件公司非常适合使用 Oinone,不管你是做标品还是定制项目，都非常适合使用Oinone 低代码：构建软件快速开发标准，让研发专注在业务创新本身 快速实施个性化需求、或开发简单和应急应用 5.我们公司产品迭代很快，用不用Oinone？ 无代码：使用Oinone 可以快速的响应需求，以及后续迭代需求； 集成平台：快速的是实施集成方案，一次配置，终身受用； 低代码：降低技术复杂度，提升研发效率，让研发专注于业务本身； 6.我们公司产品bug很多，用不用Oinone？ 很多公司都有这样的痛点，一直有BUG ，反复修反复出现，重构成本非常大，比如项目预算有限，无法支撑重新构建，技术栈老旧，研发人员比较少，Oinone 提供以下解决方案： 同步原系统数据回流处理后数据； 原系统数据扩展处理新业务逻辑； 7..我用的是JAVA 技术栈，我还需要用Oinone么？ 在探讨低代码平台的合作时，首先需要确认的是，如果您之前使用的是Java技术栈，那么低代码平台是否能够生成相应的Java代码，包括常用的增删改查等方法。这种代码生成器与低代码平台的第一种方式——代码生成器相似，它提供了基础逻辑的生成。 针对这一层面，Oinone平台具有几个显著优势。首先，后端定义的模型或写法不仅决定了后端的数据处理，同时也影响了前端的UI展示层。其次，当前端开发时加入特定的注解，这些注解的本质是为了收集原始数据。一旦数据源被定义，编写的代码在最终运行时实际上已经转变为数据。这是与传统代码编写方式的第二个不同点。第三，尽管我们提供了代码编写的方式，但这样做的核心目的在于解决标准化产品与个性化需求之间的矛盾。在进行功能扩展时，对于工程架构和代码编写的冲击较大。 oinone的核心优势在于减少代码生成量，内置代码规范，并实现前后端无需联调。此外，无代码设计器能够理解用代码构建的模型或函数，并与之结合。 在前端方面，低代码平台也提供了相应的工程结构，允许通过添加平台依赖来引入平台功能。前端的自定义能力包括自定义模板、布局和页面，以及完全自定义视图的能力。此外，平台支持前端与后端的交互自定义，以及自定义字段的引入。 总结来说，后端定义的模型不仅决定了数据存储结构和扩展方式，还决定了前端的UI展示，并能与无代码平台结合。引入TypeScript（TS）的概念，可以帮助团队最大化逻辑复用，解决了业务组件难以沉淀的问题。通过这种方式，前后端的结合更为紧密，减少了联调的需求，提高了开发效率。