如果call CRM_ORDER_MAINTAIN的时候传一个change mode = U – update，但是text content = ‘’进去能不能成功执行?
目前webclient ui上text area清空后传的是 change mode 的值为 D。
测试：
删除之前有两个text entry，然后我点下面Header text的edit icon进去：
把下面文本全部清空，
点back button：
此时传到CRM_ORDER_MAINTAIN里的mode是D-delete：
执行后UI上看不到Header text了：
用ST05也能看到delete的operation：
结果是，如果我用CRM_ORDER_MAINTAIN update text，mode设成B ( update ), 但是传入的to be updated的text ( 放在LINES )里的内容是initial的：
line 41检测到这种情况，会将text api内部的一个标示change mode的字段”function”设置成delete, 最终导致 DELETE_TEXT的调用。
也就是说我们想传一个空的string到CRM_ORDER_MAINTAIN，让这个空的string overwrite之前已经存在的text instance的这种想法现在看来走不通。
总结
-
如果是log type的text，每次call CRM_ORDER_MAINTAIN时总是creation mode
-
如果是edit type的text, 用户输入了一个非空的text：
(1)先读取对于UI传入的text object, 是否存在对应的text instance：
对于edit type的text而言， text guid，text object name ( 如上图0004 ) , text language
这三者唯一确定一个text instance。Text guid本身并不能确定一个edit text instance，因为所有edit text instance的text guid都等于其属于的opportunity guid。
Text API的输入参数不包含text change type ( P,R, ‘’ )等，只是text object和change type是1:1关系，能很容易根据text object从customizing里读取到其change type。
(2) 如果对应的instance已经存在，change mode = B – Update，否则为A - create
如果是edit type的text，用户输入了一个空的text：
还是从DB里先读取对应的text instance，如果不存在，什么也不做。
- 如果存在- change mode传B ( update ) 和 D ( delete ) 似乎都可以，因为两者最后都会trigger text deletion，只是传D的话，semantic上更清晰。
更多Jerry的原创文章，尽在："汪子熙":
