Библиотека программиста: книга «Advanced Apex Programming»

Библиотека программиста: книга «Advanced Apex Programming»

http://www.amazon.com/Advanced-Apex-Programming-Salesforce-com-Force-com/dp/193675410X/

Сразу стоит отметить, что на официальных мероприятиях СФ раздает книги, которые просто печатные версии их мануалов, но вот эта книга является одной единственной авторской книгой, которую они также бесплатно распространяют. Так что полагаю, что она есть у многих из вас.

Кстати, все примеры кода вот здесь:
http://advancedapex.com/samplecode/
так, что вам и книжка может не понадобится...

Эту книгу мы уже не раз пытались обсудить, да всё безрезультатно. Причины могут разными, не буду гадать, просто скажу за себя: мне потребовалось два с половиной года, чтобы дочитать ровно до половины (130-той страницы). Причина в том, что там описаны ситуации, которые не понятны в своей сути для новичка, особенно если не работаешь непосредственно с СРМ.
Сейчас я дочитал только до половины, но тем не менее решил начать обсуждение уже прочитанного, руководствуясь принципом, взятым из предыдущей книги: ты никогда не будешь готов на 100%, так что начинай сейчас.

Вначале книги обзорно описывается ключевые вызовы программирования на Апекс, как лимиты, управление потоком выполнения, и прочее. Здесь для многих не будет новостей.

Но запомнилась одна вещь. Требуется для выполнения операции проверить на записи комбинацию условий, состоящей из определенных значений в полях записи. Для этого нужно кверить все эти поля, потом делать проверку. Автор предлагает, а не вынести ли всю эту суету в специальное формульное поле, возвращающее тру\фальс? Тогда можно просто кверить те записи, у которых это поле в Тру, что сокращает и упрощает код, плюс в формульном поле легче апдатировать условия.

Далее буду кратко описывать некоторые запомнившиеся моменты:

Используйте Мап, чтобы получить Сет. Как я понял, Мап можно сходу создать из Листа, а для создания Сета нужно итерировать цикл.

Избегайте использовать Объект в качестве ключа Мапы. Проблема в том, что если по другой ссылке изменить объект и снова его добавить в Мапу, то он будет расценен как новый объект, а не уже существующий.

Подробно идет разбор работы тригеров, точнее управление порядком выполнения. Это всегда важно, но, как я понял, это особенно важно при кастомизации СРМ, так как там все объекты плотно связаны стандартной или кастомной логикой, и изменение одной записи вызывает целую цепочку событий...

Разумеется один тригер на объект. Но здесь мне вот какая мысль показалась интересной. Очередность выполнения множественных тригеров непредсказуема. В результате ошибка может возникать только при определённой последовательности выполнения множественных тригеров. Т.е. Это будет внезапной и неуловимой ошибкой: то она есть, то ее нет, и сложно воссоздать и словить ее в тесте...
тригерная логика выносится в классы, а сами классы имеют «защиту» от того, чтобы их действие не привели к повторноному вызову текущего тригера в течении данного контекста. В начале книги для этого предлагается использовать Статичный флаг, но в середине книги уже другая, гораздо сложная концепция: предлагается использовать Интерфейс, куда перенесены все нужные флаги.

Вот такое поле:
public static ITriggerEntry activefunction = null;

и конце работы класса вот такая операция:
TriggerArchitectureMain1.activefunction = this;

я так и не разобрал до конца как это работает, но и беглого взгляда достаточно, чтобы понять, что это хороший пример использования Интерфейса (создающего общую часть АПИ у разных классов и возможность обратиться к разным объектам как к интерфейсному типу) и редкий пример использования this.

В общем в истории про тригеры автора клонит к необходимости использовать специального фреймворка для centralized dispatching. У нас, как вы помните, тоже есть «свой» вариант такого фреймворка — это ATrigger Ильи Лещчука.

Далее автор опять разбирает ситуацию такого типа:

Trigger → Workflow снова провоцирующий тот же  → Trigger (от себя: сверх типичная ситуация, настолько частая, что я не понимаю, почему в тригерах нет специальной тригерной переменной для отсечки повторного выполнения).

в этот раз не обсуждается вариант с «отключением» повтороного выполнения тригера, а обсуждается вот какой феномен. Если первый тригер ловит изменение Probability с 10 на >10,  и в случае если на записи было 10 а стало 90, то тригер сработает. Так вот при втором заходе в тригер можно ожидать что в Trigger.old будут уже новые значения 90, а вот и нет. Содержание Trigger.old остается неизменных в течение всегда контекста выполнения. Автор предлагает собирать эти «квалифицированные» и "обработанные" в первом заходе записи в спец лист, а во втором заходе проверять по нему, была ли уже «работа» по этим записям. Я помню, проблема с  Trigger.old уже как-то обсуждалась на форуме.

Плюс в некоторых случаях тригеры вообще не срабатывают, как тригеры на Делете при каскадном удалении (т. е. не срабатывают на дочерних записях) или в некоторых случаях репарентинга записи.

Плюс, читая книгу, я внезапно для себя осознал, что рекурсивный вывоз тригера (кстати, ограниченный по глубине) не то же самое, что и повторный вызов тригера, а я не вдумываюсь, воспринимал это как одно и то же явление.