问题描述
PPR里可以维护不同的item
[外链图片转存失败(img-kgQ9SSXA-1563588671269)(user-images.githubusercontent.com/5669954/326…)]
选中某个item后能为该item维护1到多个rule
每个rule可以维护1到多个parameter, 例如下图:
[外链图片转存失败(img-k4pziMcX-1563588671270)(user-images.githubusercontent.com/5669954/326…)]
Item1维护完毕之后关闭popup window，再打开item2，当试图维护item2的rule时: 一旦从dropdown list里选择某个parameter之后：
系统的behavior 就非常怪。
n 有的时候选了dropdownlist后没有任何变化
n 有的时候选了dropdownlist之后一下多出来好几个空白行
n 有的时候选了dropdownlist之后，parameter value column自动填入一些奇怪的值(这些奇怪的值是突破口)
n 选中rule1 点删除，结果删除的behavior是”undefine”的，比如rule1并没被删除，结果其他rule被删除掉。
n 。。。
后来我发现这些奇怪的值是突破口，比如我维护item2的rule时，自动带出来的value似乎和item1已经维护的一样，但是这个自动带出来的问题也并不是总能重现，也就是说有的时候是工作正常的，有的时候是不正常的，当我debug了半天发现自己debug的是正常的case时，沮丧。。。
然后我首要任务想的就是如何让这个错误能够总是重现– 采用“错误放大法”。
最后在插入一个我自己写了很多逻辑的方法print_item_rule （line 26）之后，发现这个问题每次都能重现了！
我是怎么想到在这个地方加，而不是其他地方加？应该是凭经验和直觉。同时我在所有可疑的地方都加了log:
在仔细研究了海量的log之后，终于发现在维护item2时，从dropdownlist里面选择了一个field name之后，本来属于item2的children bol entity居然变成了item1的（这种说法不太准确，应该是说item2的children bol entity，就是当前页面上正在编辑的bol entity的guid和parent guid全部和item1的entity一致了）！这就是为什么ui上看到自动带出来的parameter value和item1的一致的原因。
item1: 5CF3FCDC6E521EE483913D1CCAAA1871
rules: 5CF3FCDC6E521EE483DCDE9762BE1038
{O:3912*\CLASS=CL_CRM_GENIL_CONTAINER_OBJECT}
-rul1: 5CF3FCDC6E521EE483DD0B877DC0D0A8
-rul2: 5CF3FCDC6E521EE483DD0BF7F0B750A8
-rul3: 5CF3FCDC6E521EE483DD0C2B8FFFD0A8
item2: 5CF3FCDC6E521EE483913B6999D03870
rules: 5CF3FCDC6E521EE483913EBE06851871
item3: 5CF3FCDC6E521ED483CE91467E8D8D34
rules: 5CF3FCDC6E521ED483CE9578CBFF8D35, parent = item id
然后我就转而需要知道在什么时候，哪段代码里发生了这种奇异的事情。经过了周五和周六的漫长debug过后，
还是没找到原因，后来脑子太混乱了，就离开电脑，在纸上把思路写下来，然后出去转了一圈回来继续，结果儿子在纸上乱画。。。
[外链图片转存失败(img-R5E3eoe0-1563588671272)(user-images.githubusercontent.com/5669954/326…)]
[外链图片转存失败(img-Fk6N4iWw-1563588671273)(user-images.githubusercontent.com/5669954/326…)]
最后在周六午夜的时候，终于找到原因了，这是PPR design的issue。
PPR rule parameter 这个node采用的key structure如下，这个key structure并不能保证不同item的不同rule的不同parameter能够唯一标识。
换句话说，如果不同item使用了同一个rule set来定义rule parameter( TABLENAME相同)，且从dropdown list里选择的parameter name 相同(FIELDNAME相同)，且相同name的rule的相对位置也相同(NUMBER_INT相同)，则框架会认为这两个rule为同一个instance，这是产生上述描述各种混乱行为的根源。
[外链图片转存失败(img-P8JES4iL-1563588671275)(user-images.githubusercontent.com/5669954/326…)]
[外链图片转存失败(img-27WG5FQN-1563588671276)(user-images.githubusercontent.com/5669954/326…)]
验证也很简单，只要我们给三个item维护rule时按照上述规则避免出现duplicate key，此时系统就工作正常。比如采用下列的组合：
item1: valid from “valid from item1”
item2: valid to “valid to item2”
item3: valid from date “2014.7.20”
这个问题从根本上解决也很容易，在key structure里加个guid即可。睡觉！
[外链图片转存失败(img-YHqiYFLi-1563588671277)(user-images.githubusercontent.com/5669954/326…)]
[外链图片转存失败(img-4C6o9UJ6-1563588671277)(user-images.githubusercontent.com/5669954/326…)]
[外链图片转存失败(img-91eJINtf-1563588671278)(user-images.githubusercontent.com/5669954/326…)]
[外链图片转存失败(img-BA9HYqLf-1563588671279)(user-images.githubusercontent.com/5669954/326…)]
[外链图片转存失败(img-n8BbMAeI-1563588671279)(user-images.githubusercontent.com/5669954/326…)]
[外链图片转存失败(img-MNcF0rTA-1563588671280)(user-images.githubusercontent.com/5669954/326…)]
[外链图片转存失败(img-b5lMZ0tT-1563588671281)(user-images.githubusercontent.com/5669954/326…)]