距离上次gMIS/吉密斯的更新差不都有半年过去了，这期间gMIS部署和使用的场景进一步扩大。最近又有新的部署并使用，在更新维护的同时，也有增加新功能，比如这次比较重要的一点是进一步地深化和加强了扩展行为操作的使用。情况较复杂，兹详述如下，以备忘。
gMIS/吉密斯 是“通用管理信息系统“软件，当我们有底气说“通用”的时候，意味着这个系统可以管理任何基于关系数据库所管理的数据，为这些数据提供面向非技术人员的人性化的操作和使用数据的途径。关系数据库，技术人员能耳熟能详地列出 Oracle、MySQL、SQLServer、SyBase等，其也是当今信息化的基础设施之一。通用的面向技术人员的，各种数据库的客户端，无论是基于命令行的还是基于GUI的（包括App和Web, 如 Navicat、PHPMyAdmin等），都有不少选择。而能够基于原始数据，直接产生能够面向非技术人员的，类似产品并不多，我们说“通用”，是我们创建了一套方法，可以针对任意指定的“字段”，无论其什么数据类型，我们都能够在gMIS/吉密斯中配置出契合其特点的输出/输入接口/界面，也即我们的 extra目录，插件式的工作，通过指定配置信息，无论这个字段是读写数据、字符串、选择项、文件、层级目录、编辑器等，均能应付自如。当一种新的数据类型、接口、界面被需要时，我们可以再通过extra方式制作并嵌入进去，这就是当我们说“通用”的底气。
一直以来，gMIS/吉密斯秉持这种“通用性”工作良好。
然而，我们深知，多样性、丰富性和复杂性才是世界的本原，我们以“通用”立命题就有某种抗自然规律的冲动，这种带有某种邪乎劲的要“包治百病”式的做法，会让人担忧，也令人不解。毕竟，这世界上没有包治百病的良药。
Fig.1 数据库数据表示层级
深度地解析，上述“通用性”是建立在对“字段”这一级别的操作上，也即，可以应对所有数据类型的字段进行操作，按照通常的数据组织结构划分 “数据库 — 数据表 — 记录 — 字段”(Fig.1)，我们实现了在“字段”级的“通用性”操作。
如果多样性和丰富性的需要是针对“记录(Row)”这一级别呢？
目前针对“记录”的操作，我们有规定的动作“add、modify、view、print、delete、search(insite, pickup)、pivot、export、copy”等，如果要增加一种或多种针对“记录”的操作，该如何操作？这种需求合理吗？常见吗？ 需要被满足吗？ 能被满足吗？ 如果能，该如何实现在“记录”层级的“通用性”？
最早我们设想，几乎所有共用的操作，针对一条数据（Row）的操作也就这么多，除了增删改查这四项基本的，我们已经很丰富地增强提供了其他多项。然而，诚如前所言，多样、丰富和复杂的客观世界，可能会有更多种针对一条数据的操作需求。这种需求是合理的，也是客观的描绘世界的必需项。这样的设计应该被满足。
初次遇到这样的需求，并令我们面对和思考这样的问题是在进行 工作流 的设计和制作上。工作流的本质也是对Row为单位的数据进行操作，但其动作已经超过了对Row本身的操作，而是Row之间发生了关系，也即一条Row可能从用户A流转到用户B，然后用户B将该Row流转到用户C等等，依此类推，而且还可能针对Row产生不同的修改。
为了满足这种需求，我们设计并实现了第一版的 ActOption 标记，这一个版本的 ActOption 在数据表的 table节点配置，并输出绑定到 act/view 界面上. 详细记录参考:
[2016] -gMIS 更新多库连接及工作流workflow
[2018] –gMIS吉密斯更新Workflow工作流、FileMgr文件柜及GTAjax等模块
这些实践，为我们最终打开 gMIS 好好与这个世界的大门，既然 ActOption 可以一种配置文件的形式嵌入到 act/view 中，那距离出现在 list 主页面的 弹出式菜单中也只有一步之遥。如果实现了某种针对 Row级别的操作，既能出现在 act/view 的窗口，也能够出现在 list主页面的弹出式菜单中，与 常规的 addmodifyviewprint等相并列，则gMIS/吉密斯就具有了好好与这个世界对话的强大话语表达能力。
于是沿着这个思路，近期我们突破了自我局限，将 ActOption 的配置通过 ido, jdo, comm/ido.js 等修改实现了自动添加到 list 主页面的 弹出式菜单，与常规操作 view/modify/print 等并列。其实现方式亦颇为曲折，大致流程可以描述为：
基于 table 的xml配置信息，配置某个
