Хотелось бы узнать что вы думаете по этому поводу.
Я ЗА разделение если это сделано с умом.
Но как показывает практика далеко не всегда это получается сделать красиво и приходится придумывать кучу костылей.
Сделай разделение внутри пакета, так пакет можно сделать бесплатным с базовой функциональностью в продавать его отдельные части.
Нормальная практика мы так делали логика БД и объекты БД была в одном пакете сама визуальная часть в другом.
Что по поводу триггеоов на одном обьекте в разных пакетах?
А сделали бы открытый блог - получили бы отличную рекламную площадку для людей в теме. Могли бы себя продвигать. А то смотришь на корпоративный сайт аж плакать хочется. Такие наверное студенты гуманитарных вузов делают на уроках информатики, а мля, фирма то айтишная, не барыг с рынка.
одним словом SEO
Согласен мне тоже нравятся! И деньги свои однозначно стоит.
Но вот я с wiki работал как рядовой пользователь на фирме. Скажу что просто так найти там ничего не возможно. Помню специально просил людей чтобы скинули прямую ссылку на доку, потому что по навигации ничего вообще найти не мог. Может если бы поработал более плотно, разобрался. Но вот такая была проблема. И кстати, не от меня одного это исходит.
Что-то вас понесло не в ту степь.
Возвращаемся на путь истинный:)
Какие еще могут быть подводные камни при разделении пакета?
по названию пакета можно узнать кто заказчик
собственно за это и дадут по шапке
Ну в принципе если это продукт не самой компании, а компания предоставляла услуги по разработке, то да, тогда наверное не стоит. Я подумал что это свой продукт, которые пилит компания, которым гордится и который продает.
Все нормальное это только разработка для других)
Забыли про ВРП. Это мой пакет и да я им горжусь, но все равно разделю:)
С managed packages и их разделением не всё так просто :-) и как обычно однозначного ответа нет.
За:
- отдельные лимиты для каждого namespace акромя total heap size, maximum CPU time, maximum transaction execution time и maximum number of unique namespaces
- maintainability - спорный вопрос
- flexibility
Против:
- maintainability - спорный вопрос
- всеми "любимые" лимиты, а конкретно уже упоминавшийся - maximum number of unique namespaces, который гласит "In a single transaction, you can only reference 10 unique namespaces. For example, suppose you have an object that executes a class in a managed package when the object is updated. Then that class updates a second object, which in turn executes a different class in a different package. Even though the second package wasn’t accessed directly by the first, because it occurs in the same transaction, it’s included in the number of namespaces being accessed in a single transaction."
В общем попилили package на 10 частей - он может сделать в 10 раз больше, но вместе уже Вальтрона из них не собрать, по-крайней мере в одной транзакции.
Пакет похоже не делиться, а полностью переписывается.
В связи с этим есть другой вопрос. Целесообразно или нет для организации АПИ использовать вебсервис ?
API для своего пакета?
Не только.
Ты хочешь чтобы оно было доступно из вне?
Это же апи. Ясное дело хочу. Но я так же хочу минимизировать количество глобальных классов.
Так можно сделать один глобальный класс с одним методом, который на вход будет принимать Object. А что в него пихать и как разбирать можно придумать. И не надо беспокоиться о глобальных классах вообще.
На счет API штука хорошая, но если она реально нужна, а просто чтобы между пакетами общаться или внутри одного орга, то нафиг не нужно.
Ну и зачем каждому клиенту открытое API? Обычно API делают где-то в одном месте, чтобы клиенты к нему обращались, а не каждый во что горазд.
Ну если только свое API не будет рассматриваться как отдельная фишка. Тогда это вообще не относится к разделению пакетов.
Можно усовершенствовать идею, предложенную Дмитрием, а именно - иметь в package API класс, который будет открывать доступ куче методов из пэкаджа, и иметь механизм, который позволит сгенерировать apex code для удобной инъекции кода в target организацию, чтобы не работать с безликим методом API. Например:
//package
public class A
{
public Object methodOne(String a, Boolean b, Integer c)
{
//do something
}
}global class API
{
global Object call(String methodID, Map<String, Object> parameters)
{
if (methodID == ‘A.methodOne’)
{
return new A().methodOne((String) parameters.get(‘a’), (Boolean) parameters.get(‘b’), (Integer) parameters.get(‘c’));
}
…
}global String generateApex()
{
return ‘public class API\n’
+ ‘{\n’
+ ‘private static final NS.API apiInstance = new NS.API();\n’
+ ’public class A\n’
+ ‘{\n’
+ ‘public Object methodOne(String a, Boolean b, Integer c)\n’
+ ‘{\n’
+ ‘return new NS.Api().call(‘A.methodOne’, new Map<String, Object>{\n’
+ ‘\’a\’ => a,\n’
+ ‘\’b\’ => b,\n’
+ ‘\’c\’ => c\n’
+ ‘});\n’
+ ’}\n’
+ ’}\n’
+ ‘}\n’;
}
}
Где NS - нэймспейс managed package. А дальше устанавливаете package, вызываете метод new NS.API.generateApex(),
копируете полученный текст и создаёте класс в target организации.
Код чисто для примера, но он должен дать представление о самой идее, а дальше его можно "причесать" и усовершенствовать.
Из плюсов - получаем не безликий класс API с непонятным одним методом, а вполне нормальную структурку с нормальными именами методов. Если вдруг понадобится полностью переписать package и заменить его - это будет достаточно просто сделать.
PS: Если реализуете эту идею - поделитесь результатом!
В очередной раз убеждаюсь что одна голова хорошо, а несколько лучше.
Собственно основная идея при разделении пакета была - улучшить perfomance и по возможности избавиться от лимитов. Для этого была полностью изменена внутрення структура, а именно сейчас все контроллеры и страницы общаются строго через JSON. Никаких REMOTE ACTION. Терпеть их не могу. Делать отдельнаю страницу и реализовывать механизм, что предложил GRES, тоже не хотелось. Но тогда как можно сделать раздельную загрузку частей страницы ? Правильно....через REST webservice ИЛИ через SOAP. Через SOAP уже реализовано, но это не самый удобный способ общения из JS. + ко всему пакет уже разделен и общаться он должен как-то с другими частями. Понятно что можно использовать глобальный класс, но тогда мы привязывается к версии пакета, а если используем вебсервис, то вроде как нет жесткой привязки к версии основного пакета.
Вот такие вот мысли.
Илья твоя идея, это продолжение моей идеи и очень даже логичное продолжение. Такую идею я уже реализовывал в другом проекте и она достаточно успешно работала. Я там даже делал динамическое связывание, то есть я контроллер генерил на лету и запускал его.
Расскажи подробнее, интересно.
Присоединяюсь к вопросу от Gres. Wilder расскажи подробнее про динамическую генерацию и запуск.
А на стороне JS ты используешь какие фреймворки? или чистый JS? Судя по твоему подходу от Visualforce на твоих страницах ничего не остается.
Так точно, почти ничего не остается. Страница строиться на HTML, при этом и верстка упрощается и скорость получения страницы существенно возрастает.
По полной программе юзается jQuery и плагины к нему.
Я недавно попробовал Ractive.js
Тоже минимальная библиотека, но жудко крутая. По мне это упрощенная копия AngularJS.
С ней разработка в разы упростилась. Теперь по возможности ее использую. От AngularJS пока отказался в виду его монструозности и не очень простой инициализации.
С Ractive.js инициализация в пару строк, и скорость как обещают на уровне, ну и все плюшки от Angular (которые я использовал) есть.
Знакомый UI-шик ее почему то не любит)
Мы же ждем! =)
Можешь уточнить у него почему?
Хотелось бы услышать экспертное мнение.
И если не сложно, можешь спросить что он считает лучшей альтернативой?
Буду признателен за информацию.
Да, да 
ждем!!!
Сейчас в мире ит столько фреймворков, у меня такое чувство что каждый день выходит по несколько штук.
Я их всех терпеть не могу. Потому что все они делают одно и тоже, но каждый уверен, что его фреймворк лучше. А на самом деле он точно такойже как и 100 предыдущих. Аж бесит
Ну каждый хочет урвать кусок пирога.
А вдруг чья-то библиотека выстрелит - товарищ прославится
ну или компания
сделай свой и забей на остальных
Ну особенно нечего там рассказывать. Было это года полтора назад, холодным изральским вечером где-то в сентябре....Шутка.. В израиле в сентябре еще теплые вечера 
Теперь по теме.
Щас уже точно и не вспомню зачем, но было сделано следующее.
1. Есть пустой класс
public class test{
}Так вот этот класс был привязан к какой-то странице.
По какому-то условию через standardController код класса менялся и запускалась эта самая страница.
вот собственно и все.
Мне интересно как это всё вообще работало? Код класса поменять, это не шубу в трусы запихивать, это на prod'е запускает тесты и может залипнуть на продолжительное время, так что динамичность под вопросом.
Бо прода тот проект не дошел. Это я на сендбоксе игрался. Хотя я знаю один пакет, который и на проде так делает.
XMLHttpRequest cannot load https://eu5.salesforce.com/services/apexrest/sourceSync/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://c.eu5.visual.force.com' is therefore not allowed access. The response had HTTP status code 401
как обычно все упирается в салесфорс. Ок. похоже пока все останется по старому, а жаль 
CORS - тоже не прокатывает. добавил https://c.eu5.visual.force.com.
Хотя в хелпе написано, что должно работать
Млин, вот чем обусловлено это разделение по поддоменам для кастомного функционала в Salesforce?
Ну вот абсолютно ВСЕ разработчики костылят чтобы обойти это проблему. Неужели это стоит того чтобы вызывать столько проблем?
Видимо это политика. Сделать жизнь разработчика веселее и что бы все работало синхронно.
Нет, а если серьезно. Есть ли какой-то реальный профит от такого разделения? Может безопасность какая-то? Никто не задумывался?
Безопастность да...но профит, только если не используют серьезные парни. Лично для меня запустить какой-то JS не такая уж и большая проблема.
А почему они убрали S-Control. По той же самой причине.
В нашел я в чем у них косяк....
Я обращаюсь на https://c.eu5.visual.force.com/services/apexrest/sourceSync....что делают эти черти
Redirect To:https://eu5.salesforce.com/services/apexrest/sourceSync, но эти дебилки прокидывают только GET, но не POST. Чисто технически я конечно могу использовать только GET, но блин что это за кастрация такая ???
В общем внедрение фреймворков процесс не быстрый, но зато результат радует. Скорость однозначно возрасла. Ушла куча геморроя, верстка просто песня. И главное в любой момент можно сделать экспорт данных почти из любого места.
Ты про какой фреймворк?
Я про jQuery и его плагины. Кстати похоже салесфорс тоже использует его только не напрямую. Загрузите стандартный лайаут и в консоли посмотрите что выдает $.
Да какой jQuery фреймворк - просто библиотека с набором функций. И внедрять его не сильно сложно - подключил и дергай функции.
Вот попробуй внедрить какой-нибудь реальный js framework (Angular, Backbone, Ember) вот тут реально будет вывих мозга. Именно вывих мозга, потому что придется думать совсем по другому - не DOM + js а настоящий MVC в браузере.