本帖最后由 meteor 于 2019-6-22 13:35 编辑
其实是有一点点啰嗦+跑题了。
容我重新梳理下..........
-----------------------------我是整理思绪的分割线----------------------------------------
首先，问题是从内置命令【数据表操作】-的目标表 的参数可以以 页面单元格值 传入开启的， 这背后的动机是
==> 能利用【母版页】的优势，来完成对“通用信息编辑保存”页面的通用设计，把现有的每个信息详情的编辑页面中调用【数据表操作】操作，迁移到【母版页】 中，而具体的详情页面只需要找个隐藏单元格，暴露出一个“当前表名”给母版页 即可。
+++++++++++++++++第一段结束，其实主题已经说完了,下面全为跑题+++++++++
接着，说到通用页面，就联想到了一般企业的ERP系统或者各路信息系统，参考市面上各种定制化或者通用的系统，70%以上的页面都是【数据列表页面】+【数据详情编辑页面】这两个，比如对销售订单做管理，就是个销售订单列表页面+销售订单编辑页面，库存管理=出入库单列表+出库单编辑+入库单编辑.......如果肤浅的看，信息系统就似乎主要就是这两种类型的页面构成。
所以，各类信息系统快速开发工具应运而生，很多打着“会打字就能做ERP”之类旗号的快速开发平台在UI层面主要就是解决的就是这两个类型页面的快速生成，不少开发平台甚至只需要完成基础数据模型（也就是数据表）的设计和配置，甚至都不需要用户去管UI，平台就自动创建好了统一的列表和详情编辑页面。
如何做到这点? 虽然有些平台甚至以AI来吹嘘，但是实际上，就是在配置数据模型的时候，需要设计人员去指定UI的一些集成化配置，例如，这个字段的中文显示名是什么，显示长短，显示位置，如果是编辑，用文本框还是下拉列表，等等。。。。
****************************问题是，这种方法好吗？**************************************
好处：只要系统开发人员（甚至可以是业务人员）只要知道业务逻辑，懂得利用平台建表等操作，UI完全不用用户操心，有些好的平台可以做到多种皮肤，多种界面风格可选。大部分情况可以快速出成果进行交付。
坏处： 都说了70%以上，那还有不到30%咋办？ 这样的平台，因为大部分是完全依赖于建模层面的配置化，那剩下的不到30%的页面和功能一旦出现（非传统列表+详情编辑），有些平台直接缴械，无法解决这30%；有些平台能灵活些，但是就需要用户花上50%+的精力去解决，而且都是黑科技级的高级技术了，需要用户向专业化开发人员转变。
-----------------------------那咱们活字格算是啥---------------------------------------------
虽然号称也快速开发平台（官方最新说法似乎是低代码），但是咱们活字格本质上和上述快速开发平台还是不同的。更多的，活字格讲究的是一种可视化开发（所见即所得），这点很神似微软系的作风，以至于我多次会产生错觉，总觉得 活字格的设计器是Visual Studio 的另一个版本。个人感觉，活字格的方向，更像是专业的代码开发者一步步逼近用户设计者。即某个功能，本来是由很专业的代码开发工程师才能完成，但是随着活字格的进化，这个功能将一步步封装到不懂代码的用户设计者也可以拿来实现。 这是活字格和上文说的其他快速开发平台的最核心的区别【纯属个人意见】。上文说的其他开发平台，是反向的，是从用户设计者一步步逼向专业的代码开发者。
####################话说，跑题跑够了没有？###########################
那飞回来把，活字格如何做到专业开发者向用户设计者逼近？ 看到那些平台在用户层面黏住初级用户的手法就是关键。因为目前活字格的每个页面都是”所见即所得“，那最大的问题也是“每次要得到就必须要见一次“，每个页面都要再画一次。这样做一个是重复劳动，二个是每次重复劳动页面风格可能都会产生细微差异。 要走向用户设计者，也为解脱专业开发者，同时结合咱们活字格的优势，该如何做？
………………………………………这才是主题……………………………………………………………………………
首先，对数据模型的UI配置还是可以考虑的，并不是说其他框架平台的东西都是糟粕，毕竟这个是他们的精华，只是到后期有所局限罢了。比如在建模时（就是建表（或者关联外联表）时，可以加上对UI界面属性的一些配置，以便可以自动化的生成一些页面（比如列表页和详情页）
PS，现有活字格有个这个功能，就是【从表生成页面】,但是应该除了做demo，应该.........没人会用把？
为啥不用？一个是因为太丑了....二是因为配置的信息不够，不足以生成足够丰富的页面。
其次，如果进一步的，这个自动生成的页面，如果符合某种自定义的可视化的【页面样式】，仅仅是替换掉不同的数据源，然后根据不同字段的UI配置在【页面样式】的限制下渲染出页面，岂不是大功告成？
关于这个问题，我前几楼只是简单说个列表页面的实现想法，还是有很多细节和详细的东西需要讨论。但这仅是一个思路，总结下：
～～~~~~~~~~~~~~~终于要总结了～～～～～～～～～～～～～～～～～～～～～～
活字格作为一个快速开发平台（或者低代码）(本质上我觉得是解放个人劳动力)，所追求的应当是不断极致化的精简业务系统设计者的工作，凡是重复做过超过2次的工作（或者相同性质的工作），理论上都需要被模式化，表象的重复工作很容易看出来，但是对工具的制作方面的重复，或者是对相同工作性质的聚合就很考验活字格官方的智慧了。这个例子是列出了一个所谓ERP系统的列表+编辑页面并加以展开，讨论活字格如何做到这个过程的自动化。因为水平有限，表述的有些不清晰，加上人又有点懒，所以有些更具体的描述以及其他系统类似的一些例子截图等就没放上来了。望包涵
|
<<<<<<<<<<<<<<<<<<<<<<<<<<<
陕公网安备：61019002000258 |
隐私政策 |
网站地图