Провокационный вопрос: Что лучше - написать Workflow Rule с Field Update'ом или использовать Apex Trigger? Естественно предполагается ситуация с которой Workflow Rule и Field Update могут справиться.
Я за триггер.
Не люблю размазывать логику по salesforce как масло по батону.
Потом это становится нереально поддерживать, особенно на большом проекте.
Код есть код, а всякие галочки быстро забываются и потом очередной разработчик ломает голову почему у него хрень какая-то происходит.
Всякие workflows, validation rules и так далее считаю лишь игрушкой для клиента и тупо маркетинговым ходом.
Это позволяет клиенту решить примитивные вопросы без разработчика, но если уже дошло дело до разработчика, то нафиг эти все штучки.
Чистый код!
Дмитрий, извини, конечно)
Но не хотел бы я с тобой работать в команде
Да я уже понял 
Мне ваша компания уже 2 раза отказывала
Ну вот и третий
Ну это всего лишь политические взгляды.
Сам то я вполне себе спокойно подстраиваюсь под любые проекты.
Сейчас отлично работаю на проекте с таким ООП что уши заворачиваются (я уже упоминал про 5-6 apex классов чтобы просто вывести sidebar на странице). Ничего тоже ООПю по полной
На самом деле это в какой-то мере шутка. Просто не понимаю твою нелюбовь к вещам из коробки.
Потому что проект (s-d.net) в принципе ничего так выглядит)
Думаю если б работали вместе, то сработались бы.
первое правила Salesforce: используй стандартный функционал везьде где только возможно.
идеальная работа разработчика - это показать твоим БА, что все что они хотят можно сделать поинт-энд-кликом и показать им как делается. На себя брать действительно сложные и интересные задачи.
но ситуации конечно могут быть разные.
Да я понимаю, тоже шучу.
Конечно если серьезно будем разговаривать (по работе), то все будет совсем по другому.
И я буду любить и знать как использовать стандартные штуки и с ООП все нормально будет.
Просто выражаю свои мысли исходя из прошлого опыта работы на проектах с большой текучкой.
Ну сколько раз видел что начинается все круто, а заканчивается в темном месте, потому что текучка, дедлайны, изменяющееся ТЗ или его отсутствие.
Поэтому я понял что все должно быть лаконично, в одном месте и максимально независимо от остального, вплоть до копипаста. И разрабатываться одним человеком. Это реальный мир 
Ничего против ваших методов разработки не имею и только рад что у вас получается делать все красиво и ваши планы не разбиваются о реалии повседневной работы компании.
Никогда не доверяйте клиенту/пользователю.
Ну или пока не достигнете уровня Дзен, чтобы разрабатывать код с учетом всех защит от дурака!
Еще раз повторю.
Когда все это один делаешь или все это делается под руководством 1 человека то можно играться всеми этими настройками и стандартными инструментами. Но если работа ведется параллельно (девелопер-девелопер, девелопер-клиент) то я могу пожелать только удачи.
Проходили не раз. Отлавливали бешеные(незарегистрированные в нашем ТЗ) workflow, time-based workflows, validation rules. Скажу, ничего приятного в этом нет.
Помню свой предпоследний проект.
Огромную полезную мысль вынес оттуда.
"Убрать от пользователя ВСЕ лишние элементы интерфейса или логировать каждый чих".
Знаете что было в проекте от стандартного salesforce? НИЧЕГО.
Были только кастомные страницы с 1-2 большими кнопками, которые еще нельзя было нажать не вовремя.
Потому что девочкам сложно и вы не представляете что они способные вытворить даже с этими 2 кнопками.
А если дать им еще стандартный UI от salesforce - будет беда.
Вы же поймите что работать будут не такие же как вы программисты Salesforce и не продвинутые пользователи, а бизнесмены, бухгалтерши, для которых чайник уже сложно.
Не, я говорил про код на github
Я БЫЛ БЫ СЧАСТЛИВ!!!
если бы salesforce предложило такое решение:
custom objects + apex + visualforce и ВСЁ!!!
Я думаю он бы пользовался успехом у русских клиентов
В этом и есть прелесть python и ruby. У них очень понятный и красивый синтаксис.
Java enterprise и рядом не стоит в плане красоты кода.
Сорри, опять затеял холивар
я кстати за триггер)
было у нас wfr + fu на практике. жопа еще та
ну допустим так, а теперь резко меняем задачу на email alert
делай вфр + алерт
тут стоит конкртная задача, а не допустим, меняем, и тд
Да, задача поставлена конкретно - именно филд апдейт.
Не раз доводилось мне слышать точку зрения, и от самих форсовцев (я имею в виду различные презентации, tutorials и пр.), что тут как нельзя лучше подойдёт стандартный функционал в любой ситуации, когда он может с этим справиться. Но тогда бы вопрос не был с подвохом :-) А расставить точки над i поможет "Triggers and Order of Execution" (привожу в сокращении главные для этого топика пункты, номера соответсвуют очереди выполнения):
...
3. Executes all before triggers.
...
7. Executes all after triggers.
...
10. Executes workflow rules.
11. If there are workflow field updates, updates the record again.
...
13. If the record was updated with workflow field updates, fires before update triggers and after update triggers one more time (and only one more time), in addition to standard validations. Custom validation rules are not run again.
Таким образом имеем, что при наличии сколь-нибудь "тяжелой" логики в before/after update триггерах (а это 90% если не больше всех случаев), да и в случаях когда этот field update может выполнится на insert, маленький Давид созданный point-and-click'ом может разбудить большущего Голиафа, спящего в apex trigger'ах. Вот и получается что Дмитрий не так уж не прав с apex'ом.
Моя версия такова, что в случае когда на объекте уже есть триггер в 99% лучше внести этот field update туда, особенно если там уже есть field update, с которыми стандартные средства не позволили справиться.
Это (наличие триггера), кстати, тоже уточнение.
Наличие тяжелой логики в триггерах тоже считаю не очень хорошей практикой.
11,13 пункты как бы логичны (нет, разве?) и логично тяжелый триггер писать учитывая это?
Не был бы против примера (гипотетического).
Под "триггером" подразумевается просто логика вынесенная в apex code - связка Trigger + Apex Code, не куча кода в самом теле триггера, с точки зрения ООП всё может быть идеально.
Пункты логичны, но про это не всегда помнят и сути это не меняет - field update запускает триггера.
Ну а вот и пример, вполне себе даже не гипотетический:
1. Первый requirement: на сохранение Opportunity в случае если Deal_Status__c changed to "Approved" произвести сложный поиск по базе (сделать n SOQL запросов) и обновить например (k DML операций) Contact какой-нибудь - без Apex'а и соответствующего триггера никак
Прошло 3 месяца с тех пор как выполнен 1-ый requirement и поступает второй:
2. Если при сохранении Opportunity Amount < 10K, автоматически Deal_Status__c ставить в "Approved" - вроде ничего сложного и имплементируется через point-and-click и field update.
А теперь у нас идёт insert двух Opportunity - в одном Deal_Status__c сразу "Approved", а у второго Amount - 5K. На выходе имеем - сложный поиск из n SOQL запросов выполнится дважды - первый раз для Opportunity со статусом "Approved", а второй раз когда второму Opportunity поменяется статус на "Approved", т.к. у него Amount < 10K, то же самое и с DML.
В итоге имеем 2n SOQL операций и 2k DML. И да, такое в жизни случается на более реальных примерах.
Уважаемые, не забывайте про нижние эдишны сэйлсфорса (Group, Professional), где триггеры/классы вообще нельзя создавать, они там только в составе пакета работают.
http://www.salesforce.com/us/developer/docs/packagingGuide/Content/dev_packages_apex_ge_pe.htm
А чего про них забывать - разработчики там не нужны. Я по крайней мере туда не пойду.
Пусть клиент сам галочки гоняет.
Если клиент этого не умеет и не понимает в чем разница между Professional и Enterprise то рано или поздно придет задача которою галочками не решишь, а заказчик будет не тебя смотреть и говорить "тыж программист".
Только код, только хардкор.
Лично я не люблю мышкотыцкать, а люблю код писать. Люблю когда все в одном месте и не надо разыскивать где и что включает и переключает.
Хотя :-) Если есть возможность сделать какой-то функционал мышкотыцкальством, делаю именно так ибо... по Феншую. СФному Феншую.
Ну и тут вопрос у меня возникает по поводу сколько вы можете себе позволить soql/dml операций в триггере? Еще и триггер для стандартного объекта =/
Писать managed packages для PE это такой геморрой, особенно если это под конкретного заказчика, а не generic package, что по-моему заказчику будет дешевле перейти на более "высокий" план.
