Стал часто замечать в чужих проектах что для хранения настроек используются custom labels вместо custom settings. Причем этим грешат не только начинающие программисты а даже те кто успел заслужить некоторый авторитет. Как раз сегодня всплыл такой случай от моего иностранного коллеги. Причем более того, чел умудрился задеплоить эти custom labels с сандбокса на прод чем перетер настройки клиента.
Это что за мода такая использовать custom labels для настроек? Или я чего-то не понимаю?
Иногда для хардкода можно заюзать, особенно если это 2-3 айдишки. Но это бывает редко, в основном конечно юзаются сеттинги
Это что за мода такая использовать custom labels для настроек? Или я чего-то не понимаю?
это называется говнокодинг мода. по-моему человек не умеет отделять котлеты от мух.
Custom labels enable developers to create multilingual applications by automatically presenting information (for example, help text or error messages) in a user’s native language.
Custom settings are similar to custom objects and enable application developers to create custom sets of data, as well as create and associate custom data for an organization, profile, or specific user. All custom settings data is exposed in the application cache, which enables efficient access without the cost of repeated queries to the database. This data can then be used by formula fields, validation rules, flows, Apex, and the SOAP API.
а что-то сеттинги в лейблах хранить это наверное я даже хз как это назвать.
это как срать стоя. имхо!
Айдишки? Хардкод? Да еще и в custom labels?
Да вы батенька знаете толк в извращениях.
Если бы у меня была команда и кто-то такое отчудил, он бы уже больше не работал 
У меня кстати в памяти всплыл похожи случай - как раз чела за хардкод айдишек и уволили
Расскажи это, когда работаешь, например, с Conga Composer и ее темплейтами. К сожалению, иногда от хардкода не уйти.Понятное дело, что айди того же рекорд тайпа никто не харкодит.
К сожалению или к счастью не работал. Но что там такого хардкорного может быть что надо айдишки в лейблах хардкодить?
PS: У нас на проекте свои темплейты, письма, и все такое, сами парсим, сами заполняем, все автоматом.
PS: У клиентов тоже есть возможность самим создавать темплейты и запихивать вские ништяки в них. А мы потом это парсим и делаем красиво.
К сожалению или к счастью не работал. Но что там такого хардкорного может быть что надо айдишки в лейблах хардкодить?
Все очень просто, Id темплейта либо репорта, его необходимо явно указывать, но это не надо делать в лейблах, данный пример про то,что иногда от хардкода не уйти
Conga - это не про email темплейты
Не, тоже не работал.
Ну если эти костыли единственный рабочий вариант, то еще простительно. Лезть внутрь пакетов то еще удовольствие. Самому когда-то приходилось вносить правки и костыли в запакованные JS либы. Понятно что при апдейте либы все может слететь, но по другому нельзя было.
Касаемо настроек в лейблах.
В кастом сэттинг можно создать текстовое поле максимум 255 символов(Если не ошибаюсь). А вот в лейблы можно залить поболее. Встречал такое когда в лейблах хранился json или xml, не помню. Плюс не надо каждый раз заполнять значениями после деплоя на новый орг. Сейчас это вроде решилось кастом методадой.
Иногда использую их когда нужно сделать настройку зависимую от языка.
Custom Metadata Types уже давно решил эту проблему:
Text Area (Long) field - 131,072 characters on separate lines.
Я так и написал)
А вот с этого момента можно начать дискуссию Custom Settings vs. Custom Metadata vs. Custom SObject
Мне что-то подсказывает что Илья хочет поделиться с нами какими-то крайне любопытными данными по этой теме.
Потому что у меня данный вопрос не вызывает особого трепета.
Custom Metadata признаюсь вообще не доводилось использовать - давно не принимал участия в разработке пакетов где их обычно используют.
Ну а по поводу Custom Settings vs. Custom SObject все предельно понятно. Используем по смыслу. Жаль только что в Custom Settings нет LongTextArea где можно хранить сложные JSON конструкции (только это оправдывает использование SObject для хранения настроек).
Не совсем, я как раз и хочу чтобы в дискуссии родилась истина 
Custom Metadata - как по мне, имеет два отличия от Custom Settings:
1. Очевидное - их можно деплоить. Это я бы назвал минусом за исключением использования для managed packages и каких-то скрытых от пользователя настроек.
2. Во время тестов данные из Custom Metadata будут доступны, а Custom Settings будут пустыми. Не знаю даже к чему это отнести, к плюсу или к минусу - с одной стороны можно забить на воссоздание конфигурации в тестах, но с другой стороны поменяв конфигурацию в Custom Metadata можно легко навернуть существующие тесты. Так что ставлю и это как минус.
В сухом остатке - Custom Metadata идеален для managed packages, в остальных случаях я бы предпочел Custom Settings.
Custom Settings vs. Custom SObject - тоже не самый очевидный батл.
Самый большой минус Custom Settings (и Custom Metadata туда же) - 10 MB per org всего. И я бы не сказал что это сильно [s]дох[s]много.
Из очевидных минусов Custom SObject - минус одна SOQL операция на вычитывание конфигурации и возможно Custom Settings не жрёт heap size.
Из очевидных плюсов: какие угодно поля и типы полей, возможность audit trail, большой объём данных.
В сухом остатке - изначально я сильно топил за Custom Settings, но что-то ограничение в 10 МB меня не радует и невозможность хранить большие 255 символов в поле... Начинаю поглядывать в сторону Custom SObject'а так как подкупает audit trail и большой объём данных.
А что это за сеттинги такие которые не влазят в 10мб? С 255 символов соглашаюсь (как писал выше про настройки в виде JSON)
Я просто больше работаю с другими языками и платформами, там тоже существует такое понятие как настройки, но везде это какая-то json/yaml/object структура где сконцентрированы ключ-значение. И никто не хранит в настройках что-то больше чем пара десятков строк. Возможно в SF немного извратили понятие Custom Settings изначально, поэтому у SF разработчиков каша в голове. Например помню когда изучал Custom Settings c типом List в примере в него запихнули коды стран и их полные названия. Ну какие это Settings? Это просто обычная таблица с данными и я бы не пихал это в Custom settings. Вообще как таковой Custom Setting List не должен существовать. Если кто-то возразит - это ж выигрыш в SOQL и heap size, то я бы посмотрел в глаза тому архитектору которые проектирует приложение в котором есть необходимость экономить на количестве SOQL за счет Custom Setting.
Проблема-то в том что в организации могут быть и другие custom settings а лимит шарится.
Дополнительный аргумент в пользу Custom Label - их можно использовать в формулах, подобное поведение правда свойственно и hierarchical Custom Settings.
