【FORGUNCY-2814】数据表操作 命令 中 "目标表" 的单元格自定义指定
本帖最后由 Simon.hu 于 2024-1-12 16:00 编辑当前的命令"数据表操作"中,目标表只能是从下拉框中进行选择(选的是当前的维护的某一数据表)
能否变成可以从单元格公式中得到?比如取自A1单元格的值
目的是为了能做一些更通用的模板页面,能更灵活的对不同的数据表进行自动化处理.
当然会有顾虑,如果A1单元格的值的表并不存在怎么办? 建议可以给个错误提示即可.
》》》》》》》》》》》》》》》》》》
这个需求的我的想法是, 我比较了excel服务器和活字格在建立普通数据的编辑详情页面的方便性和效率上,发现活字格很吃亏,主要是因为每个页面活字格的保存功能都需要 判断 新增还是修改,然后写命令调用操作数据表新增还是更新.虽然可实现,但是每个页面都要做重复的工作就很麻烦了,而且这是信息系统的基本功能,excel服务器的方便在于把这个功能集成到了他的内置功能了,所以效率提升很多.
所以,我想的解决方法是做个母版页面,针对详情编辑页面的母版页,页面占位区是具体的业务逻辑页面,在占位区外,是两个按钮:保存取消
当然,可以放上opCode,标记当前页面的操作是新增还是修改,然后在母版页实现通用的数据提交(包括新增和修改).这时候涉及到的问题就是具体业务逻辑页面所提交的表是变化的,所以如果命令能对目标表的值可以变化指定,这个问题岂不是解决了?
你也可以想象一下这样一个场景，医院采集完血液，给血液编号，同时在检测数据表里添加一条只有血液编号的记录，其他字段值留空，等待检测完成填写检测数据的时候把留空填写补充就可以了，每天有大量的血液要检测，检测的指标每个病人都不尽相同，我们看到的化验单只是结果部分，其实还有检测记录要经过数据计算才得出结果，这些只有做检测的人能到看，在检测行业所有的结果必须保留原始记录 本帖最后由 meteor 于 2019-6-22 13:35 编辑
Simon.hu 发表于 2019-6-19 13:48
可能我没有完全理解哈~
即使有这么一张表，记录那个表中有什么字段，那用户在浏览器上要怎么使用呢？
...
其实是有一点点啰嗦+跑题了。{:3_45:}
容我重新梳理下..........
-----------------------------我是整理思绪的分割线----------------------------------------
首先，问题是从内置命令【数据表操作】-的目标表 的参数可以以 页面单元格值 传入开启的，这背后的动机是
==> 能利用【母版页】的优势，来完成对“通用信息编辑保存”页面的通用设计，把现有的每个信息详情的编辑页面中调用【数据表操作】操作，迁移到【母版页】 中，而具体的详情页面只需要找个隐藏单元格，暴露出一个“当前表名”给母版页 即可。
+++++++++++++++++第一段结束，其实主题已经说完了,下面全为跑题+++++++++
接着，说到通用页面，就联想到了一般企业的ERP系统或者各路信息系统，参考市面上各种定制化或者通用的系统，70%以上的页面都是【数据列表页面】+【数据详情编辑页面】这两个，比如对销售订单做管理，就是个销售订单列表页面+销售订单编辑页面，库存管理=出入库单列表+出库单编辑+入库单编辑.......如果肤浅的看，信息系统就似乎主要就是这两种类型的页面构成。
所以，各类信息系统快速开发工具应运而生，很多打着“会打字就能做ERP”之类旗号的快速开发平台在UI层面主要就是解决的就是这两个类型页面的快速生成，不少开发平台甚至只需要完成基础数据模型（也就是数据表）的设计和配置，甚至都不需要用户去管UI，平台就自动创建好了统一的列表和详情编辑页面。
如何做到这点? 虽然有些平台甚至以AI来吹嘘，但是实际上，就是在配置数据模型的时候，需要设计人员去指定UI的一些集成化配置，例如，这个字段的中文显示名是什么，显示长短，显示位置，如果是编辑，用文本框还是下拉列表，等等。。。。
****************************问题是，这种方法好吗？**************************************
好处：只要系统开发人员（甚至可以是业务人员）只要知道业务逻辑，懂得利用平台建表等操作，UI完全不用用户操心，有些好的平台可以做到多种皮肤，多种界面风格可选。大部分情况可以快速出成果进行交付。
坏处： 都说了70%以上，那还有不到30%咋办？ 这样的平台，因为大部分是完全依赖于建模层面的配置化，那剩下的不到30%的页面和功能一旦出现（非传统列表+详情编辑），有些平台直接缴械，无法解决这30%；有些平台能灵活些，但是就需要用户花上50%+的精力去解决，而且都是黑科技级的高级技术了，需要用户向专业化开发人员转变。
-----------------------------那咱们活字格算是啥---------------------------------------------
虽然号称也快速开发平台（官方最新说法似乎是低代码），但是咱们活字格本质上和上述快速开发平台还是不同的。更多的，活字格讲究的是一种可视化开发（所见即所得），这点很神似微软系的作风，以至于我多次会产生错觉，总觉得 活字格的设计器是VisualStudio 的另一个版本。个人感觉，活字格的方向，更像是专业的代码开发者一步步逼近用户设计者。即某个功能，本来是由很专业的代码开发工程师才能完成，但是随着活字格的进化，这个功能将一步步封装到不懂代码的用户设计者也可以拿来实现。 这是活字格和上文说的其他快速开发平台的最核心的区别【纯属个人意见】。上文说的其他开发平台，是反向的，是从用户设计者一步步逼向专业的代码开发者。
####################话说，跑题跑够了没有？###########################
那飞回来把，活字格如何做到专业开发者向用户设计者逼近？ 看到那些平台在用户层面黏住初级用户的手法就是关键。因为目前活字格的每个页面都是”所见即所得“，那最大的问题也是“每次要得到就必须要见一次“，每个页面都要再画一次。这样做一个是重复劳动，二个是每次重复劳动页面风格可能都会产生细微差异。 要走向用户设计者，也为解脱专业开发者，同时结合咱们活字格的优势，该如何做？
………………………………………这才是主题……………………………………………………………………………
首先，对数据模型的UI配置还是可以考虑的，并不是说其他框架平台的东西都是糟粕，毕竟这个是他们的精华，只是到后期有所局限罢了。比如在建模时（就是建表（或者关联外联表）时，可以加上对UI界面属性的一些配置，以便可以自动化的生成一些页面（比如列表页和详情页）
PS，现有活字格有个这个功能，就是【从表生成页面】,但是应该除了做demo，应该.........没人会用把？
为啥不用？一个是因为太丑了....二是因为配置的信息不够，不足以生成足够丰富的页面。
其次，如果进一步的，这个自动生成的页面，如果符合某种自定义的可视化的【页面样式】，仅仅是替换掉不同的数据源，然后根据不同字段的UI配置在【页面样式】的限制下渲染出页面，岂不是大功告成？
关于这个问题，我前几楼只是简单说个列表页面的实现想法，还是有很多细节和详细的东西需要讨论。但这仅是一个思路，总结下：
～～~~~~~~~~~~~~~终于要总结了～～～～～～～～～～～～～～～～～～～～～～
活字格作为一个快速开发平台（或者低代码）(本质上我觉得是解放个人劳动力)，所追求的应当是不断极致化的精简业务系统设计者的工作，凡是重复做过超过2次的工作（或者相同性质的工作），理论上都需要被模式化，表象的重复工作很容易看出来，但是对工具的制作方面的重复，或者是对相同工作性质的聚合就很考验活字格官方的智慧了。这个例子是列出了一个所谓ERP系统的列表+编辑页面并加以展开，讨论活字格如何做到这个过程的自动化。因为水平有限，表述的有些不清晰，加上人又有点懒，所以有些更具体的描述以及其他系统类似的一些例子截图等就没放上来了。望包涵{:3_59:}
lwt 发表于 2019-6-10 12:01
每次做增删改查，列表确是很麻烦。
是的.
说到列表,其实也是同样一个思路,
如果做个母版页,页头 是通用的查询文本框,查询按钮,增,删,改按钮,
然后占位区是具体的页面的列表grid部分.
查询命令如果也能做到表名参数化传入,也解决这个问题了.
这样一般的列表页+详情页 的开发效率就嗖嗖的了.一下解决了通用信息系统60%的工作
Simon.hu 发表于 2019-6-18 16:38
你的意思是是说，在运行界面
在主动的选择字段个对应的单元格吗？
我举个例子来描述一下所希望实现的操作效果吧。在设计某个功能时，例如 人员信息维护，这时有几种选择（A.用活字格内置sqllite建表，B.活字格创建sqlserver表 C. 外部系统的外联表）
直接说C，因为可能是要和别的系统做的库对接，所以C是个很常用的选项。A对正式的ERP系统基本不会去选择，我感觉用A的时候仅仅是存放一些系统的配置参数。 B的话因为活字格目前的建表还不是特别完善，当然，如果把这个帖子讨论的效果实现了，应该很多时候需要独立建表的时候会选择B了。
按照选项C创建了一个外联表的关联后，这时候对活字格系统来说是迷茫的，因为他对这个外联的人员信息表一无所知（字段名通常是英文的，而大部分时候UI显示出的字段列名又需要中文，而且字段是什么格式，在列表时显示多长，这些都对列表的自动化造成极大的困扰）
这时假设活字格提供了这么一个功能，暂且先叫他“表UI属性维护”，我的下一步就是针对刚创建的这个外联表《人员信息表》，使用”表UI属性维护“功能，可以进行的操作有，对人员信息表的每个字段 预设中文显示名，设置字段的显示格式（例如是文本还是数字，当然，如果能在提取表时通过sqlserver得到字段属性映射，这项可以跳过，技术应该是可以做到的），设置字段显示的默认长度，更扩展的（设置该字段是否为通用查询选项，以及该列是否支持模糊查询，以及该列在UI表格中的显示顺序。等等）。
设置完了以上，基本也就完成了对一个实体表的列表UI的定义。 这时候要实现一个人员信息的列表（带查询）的页面，只要拖入表格组件，指定表格组件对应的表【人员信息表】，然后有个选项-【启用定义的表UI属性】，就不需要设定这个表的任何其他信息，就可以完成UI展示。
当然，也可以用现有的方法，设计期定制自己的显示。两种方法均支持，才体现活字格的兼容和快捷。
如果能实现以上，做个页面模块化组件就不是难事了，因为表格的【启用定义表属性UI】，也可以作为类似参数的形式在系统运行期动态指定，就实现了动态加载
Simon.hu 发表于 2019-6-18 09:55
我有个疑问，就是表可以自定义的话，那那些字段应该保存成那些格子的值呢？
Good Question.所以需要维护一份对“表”的定义，我相信活字格的内置表是可以做到的（可以通过读取内置表的设计配置文件得到字段的属性，是字符串还是数值之类），但是外联表这个功能就弱了许多，因为外联表不受活字格系统管控。
so ，活字格 VS excel服务器，excel服务器类的产品的“方便性”很多时候也就是取巧了这个方面，因为excel服务器在定义模板的时候，就“偷偷地”把表给定义了，即使是他们所谓外联表，也需要在他的系统内定义“视图”，而在定义“视图”的同时，也把字段的一些基本UI特性给定义了，比如字段中文显示名，数值还是文本之类。
我觉得解决办法就是对这部分数据需要在设计层面进行管控。
比如需要对设计器加个表列查询的设计显示的功能，对需要查询的表列的特性做个维护，参考我之前自己做的页面可能更直观：
当然，如果内置成活字格功能肯定会更方便，因为可以直接从外联表中导入字段，然后进行定义。
既然扩展开了，就干脆再开放下思路哈。
母版页解决的问题范畴是相对固定化的，即一个页面包括通用部分+定制部分，通用部分经一次定义，在具体的业务页面可反复复用。 但是对于页面内各个业务组件的复用，母版页就显得有些不合适了。
举个ERP常用的列表页面为例， 如下图：
从概念上，可以分作1，2，3三个区域。1为查询区，2为基本操作区，3为列表数据显示区，当然还有分页组件，是属于数据显示区的范围。
假设我们可以定义一个通用的查询组件（包含途中1区的UI部分，即一个查询框，查询按钮，查询策略下拉，以及自定义查询，当然自定义查询还会有弹出页进行选择）。只需传入查询的代码（或者查询的基表），即可输出查询语句。
再定义通用的基本操作组件(如2区)，组件向外接收弹出详情页的页面，或者具体的基表数据等。
再做具体业务页面的列表显示部分，即3区域，可将查询组件返回的结果集显示出来。
这样，ERP系统的最基本的列表页面的快速显示雏形就出来了，放置一个定义好的查询组件（配置基表），再放置基本操作组件（也是配置基表）。做具体的列表显示页面，这个可以直接在页面里用活字格的表格，三步完成。 确是是不错的思路，之前我也想过，数据表就可以用表去存储了。不过实难度可能不小。 每次做增删改查，列表确是很麻烦。 我感觉这个，你直接写一个存储过程是不是就行了？ 本帖最后由 lwt 于 2019-6-14 20:50 编辑
meteor 发表于 2019-6-13 22:38
既然扩展开了，就干脆再开放下思路哈。
母版页解决的问题范畴是相对固定化的，即一个页面包括通用部分+定 ...
你这是一种框架思维，只有资深并且做过大系统的格友才题得出这种需求，如果能实现是对活字格是翻天覆地改造。强列支持你。:hjyzw: 思路很清晰，应用场景很丰富，希望能在下个版本中看到这个功能 我有个疑问，就是表可以自定义的话，那那些字段应该保存成那些格子的值呢？