Salesforce, Javascript, PHP and Others
俗话说，标题不长没人看。
不过这篇只是做一个存档，方便分享传阅，并没有故事。
如果使用VS Code选择了SFDX Create Project with Manifest，并且使用git进行代码版本管理，建议使用如下.gitignore
/* !.gitignore !anonymous.apex !/force-app !/manifest
此配置只追踪代码所在文件夹和package.xml所在文件夹。能有效的加快git处理速度。
// Update
解释：
Line 1 忽略此路径下所有文件夹，所属文件，及子文件夹及所属文件
Line 2 不忽略自己(.gitignore)
Line 3 VScode支持apex后缀的文件作为匿名块。所以你可以配和sfdx的命令愉快的储存匿名块重复使用了。公用的匿名块放在anonymous.apex同步到repo，私用的新建一个新的不同步到repo。
Line 4 不忽略代码所在文件夹及所属文件，及子文件夹与所属文件
Line 5 不忽略Package.xml所在文件夹及所属文件，及子文件夹与所属文件
// 逐句解释更新中……
解释：
行1，行2，行3：与使用apex或者api新建或者更新数据相比， 通过Page Layout新建或者更新数据的行为会少许不同。通过Page Layout的时候会根据layout的字段属性配置提前进行一次字段格式（比如邮箱类型，电话号码格式等）/字段长度/字段是否必填等检查，才会进行后续的Trigger处理。
行4，行5：对于通过Apex或者API等方式后台创建/更新数据，虽然不会提前做一次系统级检查，但会对外键做一次检查，确保没有发生引用自己的情况。
行6，行7 ：按理说接下来无论是用过Page Layout还是通过后台，下一步都应该进入Trigger处理了吧？还不一定。这里有一个例外形况，就是如果发生了例如Opportunity Line Item或者Quote Line Item的批量创建，则会提前执行一次自定义的Validation Rule。
作为Github的拥趸，最初这篇文章的标题是《利用Github Travis CI将代码部署至FTP服务器》。本来盘算的很好，利用这篇文章，一来是记录一下自己解决的问题，二来是宣传一下Github是多好用。
众所周知，Github等一众在线同性交友代码托管平台随着开发方法论的不断进化，已经演变成了CI/CD平台。哪家平台要是说自己不支持CI/CD，都不好意思出来打招呼。而Gitbub原来并没有自己的CI/CD功能，Travis CI充当了这一角色。最近，Github也推出了自己的Gitbub Actions来弥补这一块空缺，目前仍然在beta阶段。我也申请了测试资格，但目前仍然没有轮到我。
作为个人立场，很喜欢使用Github来托管代码。以前免费账号只能托管公开仓库，而收费账户又舍不得银子，无奈只能把私有仓库分散在Bitbucket和Gitlab上。
后来大家都知道了，Github被微软收购之后，免费账号也可以托管私有仓库了。我就琢磨着把所有repo都集中到Github上吧，结果猜怎么着？Travis CI免费版仍然只能用在公开仓库上。只好作罢。
当然，这次放弃Github+Travis CI组合的原因之中，Repo必须公开是其中一方面。另一方面是在使用Travis CI时遇到了无法解决的问题。
俗话说，先有问题才有的工具，而不是先有的工具而后产生的问题。首先说这次要解决的问题是什么。
其实这个问题很简单。平时在写文章或者写插件的过程中会遇到一些不懂的web技术，然后就需要做一些小demo或者简单的概念验证放到我自己的服务器上。由于有多设备切换开发的需求，任何代码都要放在远程git上做版本管理与同步。这样的话，就会出现一个稍许繁琐的操作————改完代码之后，要先commit到本地仓库，然后再push到远程仓库，然后将本地文件通过FTP工具上传到服务器，之后在浏览器打开网站进行测试，如果有问题则循环本套操作。
如果在我将代码提交到远程仓库之后，能够自动部署到FTP上该多好啊~！
很久很久以前，在SFDX还没发布的那个年代，我曾经利用GitHub+Travis CI做过一个Salesforce StandardSetController的小Demo的自动部署。每次提交完改动，就能自动部署到指定环境。我觉得部署到FTP怎么也得比部署到Salesforce Org还要简单吧！
说干就干，由于对Travis CI还算熟悉，立马查了一下文档，自信满满的写下了如下的yml文件。
# .travis.yml
language: node_js
script:
- echo "skipping tests"
after_success:
- curl --ftp-create-dirs
-T index.html
ftp://${FTPUSER}:${FTPPASSWORD}@${FTPENDPOINT}
语言无所谓，测试跳过，直接将文件通过ftp传送到服务器上。
结果执行之后，发现不对劲了。正常传送一个文件不说是瞬间完成，也不至于10分钟都传不完，导致被Travis强行把任务中止吧？然后去FTP上瞧了一眼，文件是创建出来了，但是大小是0KB。这肯定不对劲啊，查查吧。结果查到一篇Travis的官方博客，解释他们的NAT因为什么什么原因，导致FTP的被动模式失败之类的。总之就是ftp命令不能用了。
那行，我改用sftp命令。结果这次直接报错了，说不支持sftp命令。Execuse me? 然后搜了大半天，也没找到什么靠谱的解决方案。这就让人觉得不可思议了，对于CI工具来讲，FTP上传不比连接AWS、Heroku之类的简单多了？
正在感到弱小无助之际，我想起了一直在默默当备胎的Gitlab。
Gitlab也有自己的CI/CD工具，并且是免费，且可以用在私有Repo上的。
但是Gitlab的yml文件语法与Travis不同，只好硬着头皮速读了一下Gitlab CI的yml写法。
经过不断的研究与尝试，终于写下了如下的yml文件。(其实是从sample yml文件改造出来的)
# .gitlab-ci.yml
# This file is a template, and might need editing before it works on your project.
# Full project: https://gitlab.com/pages/plain-html
pages:
stage: deploy
script:
- mkdir .public
- cp -r * .public
- mv .public public
- apt-get update -qq && apt-get install -y -qq lftp
artifacts:
paths:
- public
only:
- master
after_script:
- lftp -c "set ftp:ssl-allow no; open -u $USERNAME,$PASSWORD $HOST; mirror -Rev public/ ./ --ignore-time --parallel=10 --exclude-glob .git* --exclude .git/"
任务名称随意，artifact就是本次部署的全部文件归档，这里文件夹名字叫public。为了使用lftp命令，在脚本中提前安装lftp命令。
在CI/CD的setting页面提前配置好USERNAME, PASSWORD, HOST三个变量可以避免将敏感信息放到仓库文件中。
接下来在Gitlab仓库中启用CI/CD，就可以享受了。
其实同理，既然能用Gitlab CI部署代码到FTP，也能部署代码到Salesforce。之后还会写一篇Salesforce的兄弟篇。而这篇文章呢，也不想写CI/CD是什么，也不想谈论DevOps的优势，毕竟这种东西用关键字一搜索，满大街都是，感兴趣的人在看到文章头两个自然段之后早就自己去搜了。毕竟我说它千好万好，不如举一个实际的，好上手的例子让大家看到实实在在的东西来的实惠。
// 后记
也很长时间没有更新了。有人问我哪去了。其实。。。这期间发生了很多事情，也经历了很多事情。素材也是越攒越多。奇怪的是素材攒的越多越觉得没什么值得写的东西。可能，大家都在进步，对于Salesforce平台的基本认知已经都跨越了那道门槛，现在更需要的是Salesforce这款产品以外的，更关乎于计算机世界的、网络世界的基础知识，软件工程的基本概念。还有对于各个行业是如何运转的行业基本了解。
随着年龄增加，进入到了人生的不同阶段，会发现你完全属于你自己的时候越来越少。你逐渐被必须要承担的各种角色完全瓜分。以前争不到的东西现在更加的争不到，原来拥有的东西反而越丢越多。Whatever，要不然又能怎样呢，要不然选择随波逐流，要不然选择自己受的苦自己咽下去，你敢选第三条路吗？（摊手）
某日，一个悠闲的午后，我泡的一杯毛尖正在阳光下散发着热气。嗯，接到一个小活儿。平平稳稳，不需要经历大风大浪，不需过五关斩六将的小活儿——-导数据。
这次需要更新的数据是Product。就是那个标准SObject，Product2，三位prefix是01t。人们常说用标准SObject用多了总会遇见坑，但人生又何尝不是如此。不是
完全控制在自己手里的东西，只能去了解，去接受，最后习以为常。
果然，这次就掉坑里了。工具执行结束之后，一看Log。在1000条数据里面，有50多条报了如下的错误。
StatusCode: CANNOT_CASCADE_PRODUCT_ACTIVE
Error Message: Cannot update associated pricebook entries without the Manage Price Books permission
然后看了下报错的数据，也没什么特别明显的特征。 貌似是无差别报错。
唔。。。万事不决查文档。
很快就在《SOAP API Developer Guide》定位到了这个Status Code。
https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_calls_concepts_core_data_objects.htm
《SOAP API Developer Guide》
CANNOT_CASCADE_PRODUCT_ACTIVE
An update to a product caused by a cascade can’t be done because the associated product is active.
咦？怎么详描述的与系统返回的信息不一样？
系统反馈给我的信息是“由于没有Manage Price Books Permission, 所以无法更新关联的Pricebook”。只是说由于我没有Manage Price Books权限才报错，但是我更新Product为什么又会在意我有没有Manage Price Books的权限？
而文档给的信息是“由于product是active，所以无法完成由联级更新引起的被关联的product。 ”这写的是啥啥啥？什么叫caused by a cascade，谁是发出动作的人？是我的话我又cascade了谁？谁又Associated了我？
既然《SOAP API Developer Guide》的描述完全不知所云，那么就从系统直接反馈的错误信息入手吧。查了一下使用的账号，Profile和Permission上确实都没有PriceBook的CRUD权限。不过。。。。如果是因为没有PriceBook的权限的话，为什么绝大部分数据还更新成功了？如果真是这样，由于我没有权限，应该一条都不会成功才对。
结合两条截然不同的信息来看。线索指向了两个关键点。
1. PriceBook的权限。
2. Product的active状态。
于是做了一个试验，在没有PriceBook编辑权限的前提下，尝试去变更Product的active状态。果然报出的相同的错误信息。
就是说，如果想更新product的active状态，需要Pricebook的编辑权限。
唔。。。。
故事当然没有到此结束，不甘心的我突发奇想的在本地硬盘搜索了一下这个status code，结果在一本上古文档里发现了这样一段描述。
CANNOT_CASCADE_PRODUCT_ACTIVE
某上古文档
You cannot activate or deactivate this product without also being able to edit pricebooks.
原来错误信息还有第三个版本。这个版本明确的指出了问题的所在。
接下来是无责任脑洞推理。没有任何实锤和Evidence。
在Salesforce中，Product和Price Book是多对多的关系。一个product可以有多个Price Book，而Price Book也可以包含多个Product。Price Book Entry就是二者的Junction Object。
如果用workbench查看Price Book Entry上关联Product与Price Book的字段的关系属性，会发现该关系具有联级删除属性(cascadeDelete: true)。
所以在此推定Product与Price Book Entry，Price Book与Price Book Entry之间的关系皆为Master-Detail。
在表权限层级。
在Profile中，如果想要拥有子表的编辑权限，那么至少要拥有父表的View权限。反过来，如果连父表的view权限都没有，则子表没有任何权限。
所以，由于我没有Price Book的任何权限，导致失去Price Book Entry的所有权限。
而根据观察，Product在active状态变化的时候，会同步active状态到所有旗下的Product Book Entry。
在此推测Salesforce在Product上加了一个Trigger/Workflow/Flow/Process Builder用来用来同步active状态，而且在这个处理中特意做了权限检查。如果发现没有Price Book Entry的权限，则去检查Price Book的权限，如果也没有权限，就报错。
这也正是系统直接返回的错误信息的由来：
Cannot update associated pricebook entries without the Manage Price Books permission
至于为何错误信息出现这么多版本，我推测是由于与Product有多对多关系的不仅仅只有Price Book，所以同一个StatusCode从单一情景变为也会复用在其他的情景。所以错误信息在文档里就改成了更加泛指的版本。而这次我遇见的错误是一个很具体的场景，则出现的信息又由泛指的版本变为更加具体的版本。
脑洞完毕。我去加权限了。。
某日，又见某童鞋双手合十，指尖杵在下巴上，做福尔摩斯状。
忍不住凑了过去 。
此童鞋用眼角瞄到有人过来了，嘴角抽动了一下，欲言又止。
“别难为自己了，说说吧。”团结才是力量，对不对。
“好吧。。。”他长长的吐了一口气，手也放了下来。“事情是这样的，我有一张表叫做order。这个order有个字段叫product，会去lookup一个叫product的表。”。说着，他打开了SObject的详细页面。“现在我需要导入历史订单数据，量很大。”
我点了点头，示意他继续，因为目前为止听起来没什么。
“问题是原始数据的product字段并不是product的id，而是product的code。这样的话我没法直接导入系统。” 在我开口之前他赶紧抢先又说道，“product的种类和order的数据量都实在太大了，实在没办法用vlookup处理。已经死机好几次了。”
我弹开了他的手，接过鼠标打开了product表的定义页面。在自定义字段中找寻那个叫code的字段。唔。。。。External Id勾选了，Unique勾选了。不禁扬起了嘴角。
“看，Product的code是external Id。”我指着屏幕。
“可是我们要导入数据的是Order啊，不是Product。”
“那你先说说看，External Id在Dataloader里怎么用？”
“就是Upsert的时候，可以指定External Id，如果匹配上了就update，没匹配上就insert。”他自信的回答道。
“没错。但是还有一种用法。”
“啊？”
众所周知，lookup字段实际储存的值为ID。这也就意味着，在insert或者update数据的时候，我们要将Id写在lookup字段上。如果写的不是Id，或者Id不存在，Dataloader会告诉我们数据写入失败。
一般的情况下，如果我们只有被lookup的表中一个字段的值(Product Code)，就不得不先根据这个值(Product的Code)去查出被lookup表的id(Product的Id)，然后放在待更新数据的lookup字段上(Order的Product字段)，才能继续执行下去(Order)。
不过，老天关上了你的门，一定会打开你的窗，毕竟你才是你生活的主角，所以有主角光环。
事实上，如果你拥有的值(Product Code)是被Lookup表的External Id(Product的Code)，那么在插入数据时，可以让Dataloader根据External Id自动的将lookup字段填入对应的Id。这样就不用人工的去查找替换了。
做法如下。
1. 首先，一如往常，准备好csv，点insert，输入账号密码，选择Order，选择csv路径，下一步。
2. 然后，Create or Edit a Map, Auto-Match Fields to Columns。
3. 接下来就不一样了。在匹配完字段时候，点击Save Mapping。选择路径，填入文件名。保存sdl文件。
4. 找到刚刚保存的sdl文件，用文本编辑器打开。修改如下。保存。
#Mapping values #Wed Apr 24 19:13:21 CST 2019 # Old #PRODUCT__C=product__c # New PRODUCT__C=product__r\:code__c .........
5. 回到Datalaoder，关掉Mapping Dialog窗口，这次点击Choose an Exsiting Map，选择刚刚保存的sdl文件。
6. 一路next。
7. 恭喜插入成功。（如果Product Code存在的话）
“看，你与成功之间只差一个\:”。我拍了拍了他的肩旁。
“恩人慢走”。
总结：
1. 被lookup表需要有External ID。
2. 在SDL文件中，将lookup字段的__c变成__r（标准字段去掉Id），加上“\:”，加上External Id的API Name。insert或者update的时候使用此sdl。
3. 必须仅且只仅匹配到一条记录才可以成功写入。
参考官方文档：
https://help.salesforce.com/articleView?id=000002783&type=1
后记：
有人问我说，唉，明明写的技术相关的内容，文风为什么这么不正经？
其实原因不外乎两个。第一个是想看正八经儿的说明文就应该去看官方文档，而不是等着官方文档的翻译。Salesforce的文档和知识库是很强大和全面的。第二个是每一篇文章的灵感来源都是真实被提出过的问题，我觉得自古以来，最好的承载知识的方式就是带入情景，讲故事。官方文档似的说明文是告诉你怎么一步一步的用锤子钉钉子，而我是想用故事告诉你可以用锤子来解决钉钉子的问题。
总之，想要一个工具速查手册的话，应该去看官方文档知识库才对。
临关机睡觉前，总觉得不升级点什么睡不踏实。比如手机应用，电脑操作系统，IDE和浏览器插件之类的，都要点一圈保证是最新的。
结果今天发现没有可以更新的。。。不行，难受。那就看看Godday的host的PHP有没有新版本吧。
由于租用时间较早，当年还是PHP5.2的天下。结果PHP7都快过时了，服务器可选择的PHP版本仍然停留在PHP5。俗话说，世界上最好的PHP版本是PHP6（并没有6，直接从5到7），我退而求其次，升级到7还不行？毕竟在性能上有着天差地别。
于是乎满怀期待的点开了Program Language Version。呦，提供了
新版本 PHP5.6。行吧，总比没有强。于是痛快的选择了这个稍微高一点点的版本。
很快升级就完成了。按流程，依次点开各个服务进行回归测试。博客，正常。论坛，正常…………网盘，“No input file specified.”。糟糕了。
网盘用的是老牌私有云盘OwnCloud，网上能搜出的信息不算太多。
于是乎冷静下来，分析目前的情况。
首先，变化的只有PHP的版本，而且不是大版本变动。服务本身没有变动。
其次，其他服务，比如Wordpress等皆运行正常。
所以，推测是OwnCloud的PHP设置问题。
由于Godaddy为Shared Host，所以并不能直接修改PHP设置，而是要通过.htcaccess文件去实现基于路径的调整。随之，我找到了网盘的根目录，打开了.htcaccess。
留意到了如下片段
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
…………
</IfModule>
咦？我怎么记得RewriteEngine下面应该有个RewriteBase啊。
这小问题，于是顺手加上了“RewriteBase /”。保存。
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
…………
</IfModule>
刷新之后，还是 “No input file specified.” 。哎呀？Wordpress的配置文件就是这么写的啊。然后又开始疯狂搜索信息，发现了很多在Godaddy上部署了Owncloud的受害者遇到过相同的问题，但是都没有找到答案。
看来还是得靠自己。经过一番努力地思考，难道因为是SharedHost，所以必须用绝对路径？而且由于当年不会给子域名加SSL，所以作为早期架起的服务，Owncloud并没有分配子域名，所以不该写根目录?
于是根据Goddady的Control Panel提供的绝对路径地址，拼上Owncloud的所在路径，写在了RewriteBase中。
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /XXXX/XXXX/XXX/99999999/html/cloud/owncloud5/
RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
…………
</IfModule>
再次访问OwnCloud的URL，恢复正常。
总结，
1. RewriteEngine后面要接RewriteBase
2. 如果不是域名的根目录，要写全路径。
3. 如果相对路径不好用，尝试绝对路径。
PHP7什么时候才提供啊。。。GoDaddy！
自从Saleforce进入Lightning时代，Promise这个在前端领域耳熟能详的名词，如当年鸦片战争的坚船利炮一般，强行闯入了Salesforce开发者的世界。
也不想谈太多的技术细节，因为Promise作为ES6的新特性，汉语的，英语的，日语的资料也是林林总总的非常详细。比如阮一峰老师的《ECMAScript 6 入门》中的此章节。
其实Promise理解起来也很简单，就是按字面意思，我许诺，这事我答应你了去办。
事儿我解决了，就是resolve，没办成，就是reject。事儿办成以后咱看看下一步怎么办，就是then。如果中间出岔子了，后面的不管了，直接去找谁谁谁，就是catch。不管事儿办没办成，最后告诉我一声，就是finally。
Promise的出现可以说是为了解决Callback Hell，回调地狱。甚至还有一个网站来介绍回调地狱是什么。http://callbackhell.com/
在前端开发的上古时代，回调地狱是非常常见。在代码缩略图上
能明显的看到代码的形状是>型。
顾名思义，回调，就是我找你办事，我托你办事的时候同时也嘱咐你这件事儿办完了做什么。就是我把你处理完成时要调用的方法先传给你。
一般回调地狱发生的重灾区是多步骤的AJAX。因为AJAX调用是异步的。比如，先发AJAX请求获取一个token，然后发AJAX请求获取一个user的Id，然后再发一个AJAX请求去获得这个user的数据等等。每一步的下一步要在发出AJAX请求之前就作为回调设好。强行的将一堆异步的处理变成严格的按照先后顺序执行。
那么Promise的意义就在于，把>型的代码嵌套变成了流线型的new Promise(getToken()).then(value => getUser(value);).then(value => getRecord(value)).catch(e => console.error(e)); 在感官上更贴合“
将一堆异步的处理变成严格的按照先后顺序执行。 ”的目标。
如果说，Promise只是从>型变成了|型或者—型，好处还不够多。更重要的一点，与回调地狱写法相比，Promise提供了很好的异常处理机制。只要then链中任何一环抛出异常，都会直奔catch集中处理。
但是Promise也非完美，在极复杂情况下，比如根据上一步的返回值，要执行完全不同的业务流程，promise链就会略显无力。与此同时整条Promise链也会变的及其冗长，优点损失殆尽。还有异常处理的一些坑等有时间在讲。
所以在代码结构设计与业务流程上应尽量规避极其复杂与冗长的回调链。毕竟代码还是需要人来阅读。
Salesforce开发者也应该多去了解前端技术，看看这个世界已经发展到了什么样子，而不是固步自封在SFDC的小圈子里。
某日，
打水途中看到某位同学眉头紧锁双手合十做沉思状，于是乎忍不住凑了过去。
哦。。。原来在写Lightning Component。隐隐约约看到密密麻麻的controller.js代码感觉不妙。
“咳。”为了避免吓到他，我轻咳了一下表示进场。
只见他先是略微抬起头，之后彻底滑落到了椅子上。
“唉，事情是这样的，” 他用沙哑的嗓音说道，“最开始他们要我做一个button，点了之后去后台更新一条数据，将其字段A__c更新为a。”
他把自己从椅子上重新支了起来，指着屏幕说，“这个很简单，我放了一个attribute来存需要更新的数据的id，然后在lightning button的onClick属性指定controller的方法，在controller的方法中cmp.get那个attribute的值，之后传给apex去更新这条数据。”
我微微点头表示赞同。“没毛病。然后呢？”
“然后，他们又说，要再加一个button，点这个button之后，要给这条数据的字段A__c更新为b。OK，我在cmp中加了又一个button，然后在controller里又为了新button新建了一个方法，与之前的方法不同的是，更新的值为空。”
“也不是不可以呀。“
“对，”接下来他双眼空洞的目视前方。“然后他们又让我加三个button，点了之后分别赋值b,c,d。这时候我意识到情况不对，打算在button的conlick事件把值传给controller中的方法，这样就不用每加一个button就新加一个方法了。结果……我发现……lightning button的onclick根本不能设参数，controller的方法参数也是固定的。我没办法了……”
“我明白你的意思了”。我按住了他的肩膀。
在常规前端开发中，在button的click事件中绑定的js函数传递不同的值是常见做法。如果点击button之后，处理相同，仅是需要处理的参数不同的情况应该对代码进行合理的复用。如下例。
let foo1 = function(param1) {
console.log(param1);
}
<div>
<input type="button" name="Button" onClick="foo1('a')"/>
</div>
但是lightning button（官方文档）的onclick事件，并没有提供直接传递参数的方式。所以我们只能走曲线救国的路线。
其实很简单。
首先，在官方文档里提到，
You can retrieve the button that’s clicked by using
event.getSource(). For example, to retrieve the label on the button, useevent.getSource().get("v.label").
说明我们可以在controller的方法中拿到event的触发者——被点击的button，然后获得此button上的属性——比如Label。
那么就好办了，首先我们在lightning button上光明正大的设置value属性
<lightning:button label="button1" title="create" onclick="{!c.updateRecord}" value="a"/>
然后在controller的方法中，去get这个button的value属性，接下来正常执行业务逻辑就可以了。
({
updateRecord : function (component, event, helper) {
let targetValue = event.getSource().get("v.value");
// YOUR STATEMENT HERE ......
}
})
好了，水凉了，还得重新接一杯。
在去年年初，我们曾经讨论过Salesforce 15位ID与18位ID的话题（《关于salesforce的15位id与18位id》）。
那时候简单介绍了Salesforce的Id的组成，比如头三位为prefix，4到6位为instance code，校检位，18位ID的特性是case safe而不是大小写不敏感，等等。
那么有没有想过，Salesforce是如何知道某个字符串是不是合法的ID的呢？
虽然Apex里有Id与String两种数据类型，但是两者之间的关系却是如此暧昧与纠缠不清。
很多时候本应当使用Id型变量储存Id值，我们用String型变量去储存，然而也不会出问题。
再比如说，在SOQL中，我们在where语句中可以这么写…WHERE Id = ‘0016F000035LFXo ‘…干脆就是用的字符串。
如果是在Apex中，我们也可以使用变量…WHERE Id =: myId …，这里的变量myId无论是Id型还是String型也都不会有问题。所以粗略的看，似乎当作是一回事也没关系。
但是，如果我将字符串”ABCDEFG”赋值给ID型的变量，会怎么样呢？
如我们所料，会报异常，“ System.StringException: Invalid id: ABCDEFG ”。
这说明ID数据类型还是会对Id做合法性检查。
所以引出了最开始的问题，Salesforce是如何知道这个字符串是不是合法的ID的呢？
我只是想开橘子罐头，你却要卖我一把瑞士军刀Plus。为了用这把瑞士军刀Plus开罐头，我需要先折叠锤子，收起剪子，掰开螺丝刀……
一个只是想吃橘子罐头的人
某天，我要写一个显示某服务实时状态的页面。
动手之前感觉这个需求还是挺简单的。不就是新建一组HTML元素，然后用javascript对其中的元素赋值。So easy。
一边哼着小曲，一边就把HTML元素整整齐齐的码好了。接来下，让我看看有几个信息来源会更新HTML的值。1，2，3，4，5，6……什么？三十个模块？OK，OK，让我一个一个写，只是体力活而已。
继续阅读“关于Javascript的Proxy”