Вход | Регистрация
    1  2
1С:Предприятие :: 1С:Предприятие 8 общая

Опишите плюсы и минусы расширений конфигурации, по сравнению с внешними обработками и т.д.

Ø [Фрэнки, 24.07.20 - 21:49]
Опишите плюсы и минусы расширений конфигурации, по сравнению с внешними обработками и т.д.
Я
   Filkkore
 
17.07.20 - 13:28
Не так давно заметил что многие зачастую стараются избегать использование расширений в угоду привычным внешкам. Сразу же стало интересно почему так, ведь зачастую решение задачи расширением в сотню раз проще. Можете описать плюсы и минусы, к примеру, доработки типовой ПФ или обработки путём расширения?
   unregistered
 
101 - 24.07.20 - 10:34
(98) >> я не использую типовые конфигурации

Тогда нафига тебе сдались расширения?....
Я для себя вижу только два места применения расширений:
1. тиражирование некой универсальной доработки для однотипных конфигураций
2. расширение типовой конфигурации, стоящей на поддержке (полной или частично).
А расширение для самописки - дичь какая-то. Геморрой на ровном месте.
   Фрэнки
 
102 - 24.07.20 - 10:47
Создаешь в расширении нужный регистр и указываешь в нем привязку, что регистратором будет нужный тебе документ. Если не получится в виде документа регистратора, тогда регистр придется сделать сведений и держать его независимым.

Типовой документ даже в самом крайнем случае будет иметь процедуры обработчики:
если проведение есть, то обработка ОбработкаПроведения
есть только запись, но нет проведения - ПередЗаписью
вообще ничего нет, но есть подписка, например, ПроверитьДоступПриЗаписи - смотрим, какая процедура обработчик у такой подписки и перехватываем в Расширение именно ее, а не саму Подписку и это сработает. Можно удивляться, но захват в расширение процедур и функций просто из общих модулей работает!

Ну а дальше дописываешь все, что в голову взбредет...

Если речь идет о нетиповом объекте, вроде набора записей в чем-то - но если это же тупо новый набор и нее только запись, но и чтение в запросах по этому набору - хоть ты куда его размещай - придется написать заново. Старые типовые отчеты, АРМ и т.п. не увидят этих данных, если не напишешь нового отчета, нового запроса, динамического списка и т.д. и т.п.
   Фрэнки
 
103 - 24.07.20 - 10:52
Дописывание новых наборов данных, без нарушения свойств, структуры в целом, реквизитов объекта или его ТЧ... что там еще можно придумать...

Да просто чтоб промыть себе мозги - была уже старая можно сказать конфигурация УПП и много-много-много опыта доработок для УПП. Расширений не было, а конфигурацию нагибали кто во что горазд. Принципиально не произошло радикальной смены подходов к возможности доработок, но применение расширений просто сняло ряд ограничений, когда рань нужно было снимать объект с "замка", чтоб к нему пристегнуться, а теперь - нет.
   Фрэнки
 
104 - 24.07.20 - 10:59
(101)// А расширение для самописки - дичь какая-то


Самописки бывают разные. Если это просто тупая херня из пары документов и пары регистров, накорябанная в одну пару рук - ну и не нужно никаких расширений, 
т.к. все переписывается легко и просто.

Это как мне говорили - а зачем при разработке самописной конфиги использовать хранилище конфигурации?!

Так-то определи срок разработки проекта года в три и количество участников работы в нем с возможностью замен минимум в три разработчика постоянных на проекте...
Ну и количество разработанных объектов в проекте сопоставимое с аналогичной типовой, скажем, примерно под 20 видов документов ну и всю остальную обвязку...
И почему нельзя при этом использовать все возможности платформы, которые предоставляются?!
   tgu82
 
105 - 24.07.20 - 11:13
Мне всегда казалось что скажем Оперативный учет можно под себя менять как угодно но оставляя выгрузку в бухгалтерию. А вот в бухгалтерии ничего по возможности не менять чтоб не ломать голову с обновлениями. Это я про 7-ку. В той же комплексной народ работает, но если она переписана сильно то каждое обновление еще тот геморрой поэтому мы ушли много лет назад на разделение ТИС-БУХ-ЗИК.
Что касается 8-ки. Пример для тех кто ведет учет в БП3. В документе "Отчет производства за смену" только один склад можно указать (то есть и сырье с него списывается и продукция на него приходуется). Если взять ПУБ 7.7 то там два скалад можно выбирать. Вот и мне желательно чтобы в БП 3.0 было два склада (то есть изменения в интерфейсе и в процедуре проведения). Вот как лучше делать - через расширение или через редактирование конфы ?
   Фрэнки
 
106 - 24.07.20 - 12:02
(105) В расширении пишешь под себя свой АРМ и крутишь типовыми документами, даже не изменяя в них состав реквизитов тч и шапки.
Т.е. если у тебя данная конкретная проблема ограничена просто вопросом, что нет возможности провести некий набор данных с использованием одного экземпляра документ-объекта, не ломаешь ничего типового, а прикручиваешь нужное рядом.

Если нужен аналог такого поведения, то посмотри на работу по Выпискам банка, в которых создается множество документов списаний или поступлений  расчетный счет, а вот документа Выписка даже не существует.
   lucbak
 
107 - 24.07.20 - 12:17
(101) Видимо ты просто не в курсе, что есть жизнь и за пределами типовых конфигураций... что тиражными конфигурациями бывают не только типовые...
   tgu82
 
108 - 24.07.20 - 14:04
(106) Да даже можно просто. Где-то создать константу СкладДляПродукции и потом через расширения немного переписать модуль проведения документа "Отчет производства за смену". Все ж тоже самое. Списание сырья оттуда а оприходование готовой продукции отсюда
   Фрэнки
 
109 - 24.07.20 - 14:48
(108) Обычно я сталкиваюсь, когда сырье или материалы или ПФ идут с разных складов.
ОПЗС на закладке Материалы может быть не пустой только для самых обобщенных случаев учета.
   unregistered
 
110 - 24.07.20 - 15:21
(104) >> а зачем при разработке самописной конфиги использовать хранилище конфигурации?

Здесь как раз использование хранилища обосновано.
Хранилище решает две задачи:
1. Групповая разработка, когда над проектом работают несколько человек.
2. Хранение истории любых изменений. Даже если разработчик один, это может быть востребовано.

А вот необходимость использования расширения остаётся для меня необъяснимой загадкой.
Ни одной веской причины для их применения на самописках я не вижу. Если только самописка не на поддержке, а ты сторонний относительно этой самописки разработчик.

>> почему нельзя при этом использовать все возможности платформы, которые предоставляются?

А ещё платформа умеет решать системы линейных уравнений. Ты это тоже обязательно используешь в каждом проекте?...
   unregistered
 
111 - 24.07.20 - 15:31
(107) >> тиражными конфигурациями бывают не только типовые...

Под типовыми я понимаю любое тиражное решение, находящееся на поддержке у поставщика.
И не важно - кто этот поставщик и разработчик - 1С, РАРУС, БиТ или ООО "Рога и копыта" с какими-то своими отраслевыми решениями.
А если у конфы ещё и не одна поставка, это может вообще превратиться в ад. Мы такое извращение у себя уже пробовали, когда расширения не умели расширять данные.

Расширение в таком случае должно (как предполагалось) решать конфликт доработок с обновлениями этого поставщика.
Но в жизни всё немножко не так красиво, как на картинках с сайта 1С. Слишком часто расширение конфликтует с обновлениями от поставщика, когда поставщик решает переписать те объекты и модули конфигурации, которые решил расширить (доработать через расширение). Любая достаточно серьёзная доработка через расширение (не просто вывести свой не типовой реквизит на форму) влечёт множество проблем с совместимостью с доработками поставщика в каждом обновлении. Не говоря уже о совместимости между собой различных расширений.
   unregistered
 
112 - 24.07.20 - 15:38
(108) >> потом через расширения немного переписать модуль проведения документа "Отчет производства за смену"

А потом после каждого обновления проверять - совместима ли твоя доработка в расширении с тем, что прилетело в этом модуле с обновлением.
Такие вещи надо делать либо в самой конфе. Тогда ты будешь видеть в окне сравнения-объединения все различия - в исходной конфе поставщика, в твоей конфе, в новой конфе поставщика. Либо через подписки, чтобы твое проведение/допроведение работало совершенно независимо от типовых механизмов.

Менять общие модули и модули проведения в расширении - последнее дело. 90% проблем при обновлениях возникает именно от этого. Уж больно часто 1С-ники любят пересматривать методики и подходы, перетаскивать процедуры и функции из общих модулей в модули менеджера и обратно, или таскать куски кода из одних процедур в другие.
   lucbak
 
113 - 24.07.20 - 16:49
(112) так вот "самописка" и находиться на поддержке. По хорошему в конфу поставщика вообще нефиг лазить - расширение справляется практически с любой задачей. Понятие "встраиваемых подсистем" (изменение конфы) вообще должно умереть.
   lucbak
 
114 - 24.07.20 - 16:54
+(113)ПисАть нужно изначально по-человечески, что бы у людей даже мысли не возникало снять конфу с поддержки.
   unregistered
 
115 - 24.07.20 - 17:10
(114) Это ты разработчикам тиражных решений расскажи.
А так же тем заказчикам, чей бизнес не укладывается на 100% в прокрустово ложе тех методик, которые реализованы в этих самых тиражных решениях. 90% пользователей вполне себе укладываются в типовые методики (хоть и не всегда понимают это). Но всегда есть 10% тех, кого никогда не устроит полностью методика, заложенная разработчиками тиражного решения. Кому по-любому придется допиливать конфигурацию под себя.
   lucbak
 
116 - 24.07.20 - 17:14
(115) так вот для "допиливание" под себя и придуманы расширения. Другое дело, что в типовых (которые я видел) "поддержка" писателей расширений сделана на "от...бись".
Но при этом час механизм расширений шикарен (даже несмотря на текущие недостатки которые с нем присутствуют)
   unregistered
 
117 - 24.07.20 - 17:19
(113) Самописка не может находиться на поддержке.
Самописка - это конфигурация, которую ты сам написал и сам поддерживаешь.
Делать в самописке поставку и пытаться через неё обновляться - очень странное извращение. Бессмысленное и беспощадное.

Мы такой фигнёй страдали когда-то. Но это была попытка сделать микро-тиражное решение, которое работало бы в нескольких базах.
Когда нам надо было что-то в нём поменять - мы брали, меняли и публиковали обновление. Идеи клепать ради этого ещё и расширение никому и в голову не приходила.
   lucbak
 
118 - 24.07.20 - 17:19
(115) >>Это ты разработчикам тиражных решений расскажи

Всегда ставлю себя на место тех, кто будет писАть расширения - поэтому даю все возможные механизмы, что бы у людей не было необходимости снимать конфу с поддержки.
   lucbak
 
119 - 24.07.20 - 17:20
(117) так ты определись с понятиями, что такое самописка и может ли она быть тиражной.
   unregistered
 
120 - 24.07.20 - 17:53
(119) Я все определения довольно четко дал. Перечитай ещё раз, если что-то непонятно.
Самописка может стоять на поддержке (никто не запрещает этого делать), но это скорее некоторое исключение из правил.
Сам механизм поставок и поддержки предназначен для тиражирования. Использовать его на одной единственной базе данных, конфигурацию которой ты сам написал, - дичь. Для этого надо иметь очень веские основания. Я, например, себе такие с большим трудом могу представить.
Зачем? Создать поставку, поставить конфигурацию на поддержку, а потом ради доработок вместо того, чтобы дорабатывать эту поставку, лепить расширения? НА..УЯ?... Какой в этом смысл?
Мы когда делали поставку, если надо было внести изменения, мы вносили их в поставку и публиковали его. Всё.

Может я чего-то в этой жизни не знаю или не понимаю...
Приведи пример, где ты написал конфигурацию, слепил для неё поставку, держишь некую продуктивную базу на поддержке у этой поставки, и при этом стряпаешь для этой базы расширения вместо того, чтобы дорабатывать свою же собственную поставку.
   lucbak
 
121 - 24.07.20 - 17:59
(120) один из нас видимо чего не понимает :)
Я пишу конфу, выпускаю обновления, выкладываю а клиенты это обновления скачивают и обновляются. Что я должен сделать ? Хотелки различных клиентов добавлять в конфу ? Конфа единая - одна для всех клиентов. У всех клиентов конфа находиться на поддержке. Когда я выпускаю новое обновление - клиенты скачивают и обновляются. Если клиенту требуются специфические доработки то все это делается через расширения.
   Aleksey
 
122 - 24.07.20 - 19:10
(121) "Под типовыми я понимаю любое тиражное решение, находящееся на поддержке у поставщика.
И не важно - кто этот поставщик и разработчик - 1С, РАРУС, БиТ или ООО "Рога и копыта" с какими-то своими отраслевыми решениями." (с) (111)

Т.е. у тебя тиражное решение, а не самописка, у тебя решения " находящееся на поддержке у поставщика ... поставщик и разработчик - ООО "Рога и копыта""
   unregistered
 
123 - 24.07.20 - 19:59
(121) Ну так это не самописка, а тиражное решение. Оно ничем не отличается от любой типовой конфигурации от 1С. Кроме масштабов распространения. Не называют же программисты, работающие в самой 1С, свои конфигурации самописками. Хотя пишут их сами.
Когда речь идёт о небольших доработках, делать их через расширения вполне разумное решение. В особенности, когда ты сам знаешь свою конфигурацию и четко себе представляешь - что и как можно расширять.
Когда же речь идёт о достаточно серьёзных доработках конфигурации, стоящей на поставке, которую не ты разрабатываешь, никто не даст гарантии, что допиленный тобою в расширении объект завтра поставщик не переделает до такой степени, что твоё расширение отвалиться. И далеко не все проблемы решаются за счет аккуратности, вдумчивости и внимательности.
Одно дело - дополнительный отчет или обработка, другое - добавить реквизитик какой-нибудь, и совсем третье - переписать проведение какого-нибудь ключевого документа по подсистеме НДС или бухучету в какой-нибудь БП, или (прости господи) ERP. Последнее делать через расширение выйдет себе дороже. Ну не умеют (и никогда не смогут) расширения контролировать изменение логики расширенного объекта во времени. Слишком нетривиальная это задача - понять как именно и какие конкретно изменения в исходной конфигурации повлияют на расширение.
   Фрэнки
 
124 - 24.07.20 - 21:49
если бы это не было таким явным бредом, я бы ветку не трогал... А так...
  1  2

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.