|
21.03.2017, 08:58 | #1 |
Участник
|
Цитата:
|
|
21.03.2017, 09:38 | #2 |
Участник
|
Цитата:
Сообщение от belugin
Судя по вопросу Маззи, его больше интересует вопрос, как протащить туда свои параметры, учитывая что стандартный функционал уже передает примитивы, а не расширяемый объект-критерий.
здесь тема: Как правильно вести разработку в условиях, когда часть кода закрыта от изменения |
|
22.03.2017, 02:55 | #3 |
NavAx
|
Цитата:
Так вот, по правильному, конечно же, стоило бы переписать стандарт так, чтобы не было нужды ковыряться в мешанине. Четкое, хорошо задукоментированное API. И обновления по всему миру должны выходить с оперативностью 1С. Даже в регионах, которые с точки зрения объемов продаж, кажутся маловажными.
__________________
Isn't it nice when things just work? |
|
|
За это сообщение автора поблагодарили: mazzy (2), ax_mct (10). |
22.03.2017, 08:28 | #4 |
Участник
|
Цитата:
мало того, я бы даже сформулировал "вендор должен переписать" ))) я предлагаю сразу пропустить тривиальные шаги и сформулировать тему следующим образом: Как вести разработку с минимальными в долгосрочной перспективе трудозатратами в условиях, есть куча унаследованного кода И часть кода закрыта от изменения, а платформа предоставляет систему событий и подписок? Что должен внести в код вендор? Какие техники и приемы может применять партнер/клиент? ========================= пока прозвучали варианты: = снять ограничения и писать поверх (лицензионным или нелицензионным способом) = врезаться в существующие event'ы. === при этом ожидается что будет дублирование кода === один из крайних вариантов - полное дублирование - врезаться в событие "загрузка системы" и после этого не отдавать управление стандартному приложению ограничения, насколько я понимаю: = в закрытые объекты новые евенты добавить нельзя = подписчик может не иметь доступа к паблишеру события, поэтому часть информации возможно придется передавать через глобальные переменные доводы в пользу закрытого кода (см. жаркие холивары 90х и начала 2000х о закрытых/открытых системах): = обновление на новую версию становится очень легким за счет усложнения первоначальной разработки и кастомизации ========================= еще соображения? какие ближайшие аналоги вы можете привести? другими словами, где можно посмотреть как действуют люди в подобных ситуациях? я абсолютно не верю, что ситуация с dynamics является уникальной и ни на что не похожей. значит, кто-то и как-то уже решал подобные задачи. будем применять тот опыт или не будем - можно решить после того, как посмотрим на аналоги. Последний раз редактировалось mazzy; 22.03.2017 в 08:42. |
|