我一直对form 都感觉比较困惑, 特别是form 里面的trigger, 像PRE-QUERY, POST-QUERY 一直都弄不清情况. 这个trigger 是什么时候触发的呢? 看名字就是在QUERY 之前或之后触发的. 那么QUERY 什么呢? 搞不清楚. 今天就看下代码, 弄明白点了 find 之后做了什么事
我一直对form 都感觉比较困惑, 特别是form 里面的trigger, 像PRE-QUERY, POST-QUERY 一直都弄不清情况. 这个trigger 是什么时候触发的呢? 看名字就是在QUERY 之前或之后触发的. 那么QUERY 什么呢? 搞不清楚.
今天就看下代码, 弄明白点了 "find" 之后做了什么事情, 那些数据库里面的值怎么到form 界面上去的.
我们知道, 每一个form 上的数据块都是绑定一个table 或者 view 的. 通常会绑定view. 像下面那样:
vcu1REVNX09SREVSX1YsIMi7uvOw0XZpZXcgwO/D5rXE19a2ztK70ru21NOm09rK/b7dv+m1xNfWts4sINXi0fmx4NLr1MvQ0LXEyrG68iwg1Npmb3JtIL3nw+ayy7Wlyc8gdmlldyAtJmd0OyBxdWVyeSBieSAtJmd0OyBydW4sIL7Nv8nS1NaxvdPX9rLp0a+1xLav1/csINTaZm9ybSC958Pmyc++zbvhz9TKvrP2yv2+3b/itcS8x8K8LjwvcD4KPHA+ICAgICDV4sDvvs3X9sHL0ru0zlFVRVJZILXEtq/X9ywgsunRr8r9vt2/4iwgyLu687DRvMfCvLXEJiMyMDU0MDvM7rW9ttTTprXEZmllbGQgwO/D5silLjwvcD4KPHA+ICAgICC1q8rH1eLR+bXEwt+8rcrHvPK1pbXELCDDu9PQsOy3qNOmuLZFQlMguLTU07XE0rXO8cLfvK0uINLytMvU2sq1vMq1xNf2t6jW0CwgsqLDu9PQ08PV4tH5vPK1pdaxvdO1xLe9yr0uIM7Sw8fIpb+0RUJTIMDvw+a1xGZvcm0sIMr9vt2/4snPtcTX1rbOus12aWV3IMDvw+a1xNfWts68uLr1w7vT0LbU06a52M+1LiAmIzIwMjg0O7r1ysfBvbj2srvP4LnYway1xLarzvcsINa7ysfD+9fWutzP8S48L3A+CjxwPiAgICAg1eLR+df2tcS94bn7vs3Kx7y4uvXL+dPQtcTQ0M6qtrzSqtfUvLrQtLT6wuvKtc/WLiCyu8Tcz/HJz8PmxMfR+bXjz8Ky6dGvLCDIu7rzy/nT0LXEJiMyMDU0MDvX1Lavz9TKvtTavefD5snPwcsuINPJ09rIscnZyv2+3b/i0+u958Pm19a2zrXEudjBqiwgvLTKubLp0a/By8r9vt2/4iwg0rLSqsrWtq+w0SYjMjA1NDA7uLTWxrj4vefD5snPtcTX1rbOLjwvcD4KPHA+ICAgICDO0sPH0tRQTyBSZWNlaXB0cyC958PmzqrA/Swgv7S/tLXjz8ImcXVvdDtmaW5kJnF1b3Q7ILa81/bBy8TE0KnKwsfpLjwvcD4KPHA+MS4gytfPyM6qwcu88ruvzsrM4iwgztLDx9XiwO/Wu7+8wsdSQ1ZSQ0VSQy5mbWIg1eK49mZvcm0g1rvT0MG9uPbK/b7dv+kgYSkgRmluZCAgIGIpUkNWX1RSQU5TQUNUSU9OPC9wPgo8cD7U2kZpbmQgvefD5snPzO7QtLrDsunRr8z1vP668ywgtePSu8/CJnF1b3Q7ZmluZCZxdW90Oywg1eLKsbvhs/a3oldIRU4tQlVUVE9OLVBSRVNTRUQg1eK49nRyaWdnZXIuINTa1eK49nRyaWdnZXIgwO/D5s/ItffTw0FQUF9TVEFOREFSRC5BUFBfVkFMSURBVEUgKFJFQ09SRF9TQ09QRSkg1/bR6dakLCDIu7rztffTw8HLRklORF9CVVRUT05fQ09ERSDV4rj2t723qC4gPC9wPgo8cD7U2tXiuPa3vbeowO/D5iwgtffTw8HLUkNWX0ZJTkRfQy5GSU5EX0JVVFRPTig="WHEN-BUTTON-PRESSED','FIND','RCV_TRANSACTION') 这个过程.
这时在RCVCOFND.pld 里面定义的一个过程. 这个文件是一个比较底层的文件, Receipts form 从这个from 上继承了很多, 也调用里面的方法.
这个方法里面有3 个参数, 第一个是trigger 名. 第二个是find block name, 第三个是navigation block name. 那么调用这个过程会去到RCV_TRANSACTION 这个数据块, 然后做查询, 用下面的代码来实现:
go_block(navigation block name);
do_key('EXECUTE_QUERY');
2. 那么这时焦点就会跑到RCV_TRANSACTION 这个块上去, 然后做查询. 查询什么呢? 就是查询这个数据块所绑定的view.
在做查询之前, 我们要在RCV_TRANSACTION 这个数据块下面找到了PRE-QUERY 和 POST-QUERY 这两个trigger. 这两个是干嘛的呢? 就是在做QUERY 之前给查询做一些准备工作, 和查询结束之后进行一些后续工作. PRE-QUERY 只在查询之前执行一次, 但是POST-QUERY 要在查询之后触发多次. 查询到多少条记录就出发多少次.
3. 现在来看PRE-QUERY 里面做了什么.
先是调用了这个过程: analyze_search_criteria(l_rcv_view, l_dest_query_pos, l_src_type); 看名字能看出来是在做什么... 分析查询条件. 这3 个参数属性都是OUT. 在这个过程里面确定了查询使用的view: l_rcv_view 是那个. 比如说, 如果我们做的是一个组织间转移 inter org transfer, 那么使用的view 就是RCV_ENTER_RECEIPTS_INTERNAL_V; 如果是ASN 接收的话, 使用的view 是RCV_ENTER_RECEIPTS_ASN_V; 使用哪个view 做查询就是在这个过程里面决定的. 决定标准是根据"Find" form 界面上填入的查询条件. l_dest_query_pos 意思是使用的查询方式, 有"from" 和 "where" 两种取值可能. l_src_type 就是source type, 可能是INTERNAL, LCM, CUSTOMER, VENDOR, ALL 等等;
我们这里考虑l_dest_query_pos = where 的情况.
这里面会用下面这个过程APP_QUERY.append(block_name, clause) 把 clause 加到前面block_name 后面, 作为查询条件.
4. 就这样通过判断find form 里面填入的值, 给查询的数据块加入一个一个条件. 比如, 如果FIND.SOURCE_TYPE 的值是VENDOR, 加上的查询条件就是: (RCV_ENTER_RECEIPTS_V.SOURCE_TYPE_CODE = ''VENDOR'' OR RCV_ENTER_RECEIPTS_V.SOURCE_TYPE_CODE = ''ASN''). 诸如此类.
5. PRE-QUERY 还做了一件事, 就是把find 界面上的值copy 给RCV_TRANSACTION 对应的字段. 但是这些不是作为查询条件来的.
6. 就这样在PRE-QUERY 里面确定了查询使用哪个view, 并且确定了查询条件. 然后就是做查询的动作. 查询是从前面的RCV_ENTER_RECEIPTS_INTERNAL_V 和RCV_TRANSACTION 绑定的view RCV_ENTER_RECEIPTS_V 两个view 里面查出结果来. 当查询结束后, 就会执行POST-QUERY 这个trigger.
7. 之前我们说过, 由于RCV_TRANSACTION 这个数据块上的字段和view 里面的字段是没有绑定关系的, 因此查询出来的结果并不会自动赋值给界面上的字段. 需要在POST-QUERY 里面手动赋值. 所以这个trigger 主要就是做的赋值的工作. 这个里面有大量的代码, 格式很单一:
if (criteria ) then select a into b from table where .. copy (b , 'RCV_TRANSACTION.field');
也就是根据某个条件从数据库查出某个值, 赋值给数据库的字段. 所以这个里面出现了大量select 语句和copy 语句.
8. 在POST-QUERY 里面也调用了非常多的数据库过程, 这些过程写在 pls 文件中. 这里没有去深究这许多过程有哪些功能, 但能从调用的结果上看出来, 这里面是做了一些逻辑判断和计算的. 例如v_secondary_quantity := inv_convert.inv_um_convert
9. 另外在这个trigger 的最后会set 字段的属性, 例如set_item_property: item_is_valid, 就是让字段验证属性为真.
10. 到这里为止, query 的动作就做完了, 通过PRE-QUERY 设定查询条件, POST-QUERY 给界面字段赋值. 要注意的是, 如果查询出来有两条记录的话, 那么POST-QUERY 会执行两次. 为啥要执行两次呢? 因为界面上两条记录的字段是不一样的, 需要根据不同的条件赋值, 比如两条记录的id 不一样, 就要用这个id 分别查出某个字段的值在赋值.
11. 到这里为止, 上面的RCV_FIND_C.FIND_BUTTON('WHEN-BUTTON-PRESSED','FIND','RCV_TRANSACTION') 这个过程就执行完了. 在此之后又执行了一下过程, 但是已经更查询的关系不大了, 主要是跳到某个窗口, 设置属性等等. 至此, WHEN-BUTTON-PRESSED 这个trigger 就全部执行完毕了. 查询的结果就已经在界面上显示出来了.
12. 在焦点跳入RCV_TRANSACTION 数据块的时候, 又会出发WHEN-NEW-RECORD-INSTANCE 等等trigger, 但这是后事了, 这里就不讨论了;
总结: 这样的做法显得非常复杂而且需要写很多代码, 但是优点也是比较明显的, 这对于所有的字段都有比较精确的控制. 这对于实现复杂的业务逻辑是必须的.
代码中有许多built-in 的代码, 可以在form builder 里面找看看是怎么用的. 帮助很大.
注: 这是我看着代码写出来的, 如果里面有错误的地方, 希望大家能够指出来, 共同进步.
