背景:如图,有人问到这个功能分组是怎么存储的,之前没了解过,我们来寻找下。
分析:
苍穹都是通过实体储存数据的,名称一般也都是一致的,我们第一步应该去设计器里搜索:功能分组。然后我们一眼看到这个基础资料,其他都是动态表单,不能存储数据,那肯定是这个。(太乐观了,直接踩坑了)
找到这个实体的物理表,我们看到一共才298条数据,隐约觉得太少了。搜索下我们自己的分组编码。发现竟然找不到。
奇了怪了,难道不在这里?没办法,继续寻找。ctrl+alt+g进入到新增功能分组的页面。发现标识是bos_devp_metadataunit,是个动态表单。那我们要找到他的插件,kd.bos.devportal.plugin.BizUnitPlugin。
进入插件,我们找到确定按钮的点击,发现在beforeClick事件中有逻辑。
我们找到新增分组的实现逻辑。分组是存储在应用元数据中的,应用元数据我们比较熟悉,实体是bos_devportal_bizapp,物理表是t_meta_bizapp。
我们找打物理表t_meta_bizapp,再找到我们的测试应用,发现fdata存储的元数据中就包括了我们的功能分组菜单信息。此刻我们找到了功能分组的存储位置,那页面是怎么关联到分组的呢?
我们思考一下,应该是页面创建完成的时候建立的关系,那我们通过ctrl+alt+g找到页面创建向导。发现这是个动态表单,我们找到插件kd.bos.devportal.page.plugin.BizPageNewTemplatePcPlugin,并找到完成创建的按钮。
进入插件我们找按钮的事件,发现调用到finish事件。
继续分析我们发现,都是调用了DevportalUtil.buildNewPage这个方法保存的数据。
进入该方法我们发现这里有个bos_devportal_unitrelform的实体,见名知意,感觉和我们找的关联表很像。
设计器里搜索,发现这是个基础资料,表名T_meta_bizunitrelform,有三个字段。
在数据库验证下,根据我们之前找到的应用元数据中的功能分组过滤下数据,发现是有数据的,FFORMID也能对应上我们的实体页面id。到此完成。
总结:
功能分组本身的信息是存储到应用元数据 bos_devportal_bizapp 中的。
分组和页面的关联信息在 bos_devportal_unitrelform 这个实体中。
有个功能分组的基础资料 bos_devportal_bizunit,实际上没有用到,应该是旧的逻辑,防止踩坑。
推荐阅读