А почему вас расширения 1С8х не устраивают? Или, проблема именно в том, чтобы передать, в терминах С / С++, указатель на функцию как параметр?
Предположу, что претензии не к принципиальной невозможности что-то сделать (хотя надо всегда учитывать, что 99% 1С-ников, да и вообще разработчиков, работают с кем-то до них придуманной архитектурой решения, и любые попытки привнести "свежий взгляд" могут нарваться на суровую реальность легаси и/или непонимания коллег), а к синтаксическому сахару и удобству отладки / сопровождения.
P.S. Если не путаю, то в библитеке БПО на автоматически подключаемых расширениях построена работа с торговым оборудованием, когда в основной конфигурации есть только пустые экспортные методы, а их поведение определяется текущим подключенным расширением. Задачу конечно решает, и даже в некоторой степени "элегантно", но это как предлагать сменить C на ASM с макросами. Слишком много секса в гамаке на лыжах. Хотя со временем обрастаешь готовым кодом, набиваешь руку, нарабатываешь подходы, и вот уже все это не кажется странным, и без лыж и гамака даже удовольствие кажется не тем.
Опять же, делая скидку на реалии другой страны, в те времена когда я этим занимался, часто бывало, что импорт/экспорт при измениях в формате файлов я делал раньше, чем он официально появлялся в поставках местных франчайзи (в т.ч. у оф. представительства 1С). Значит что-то с инсайдами у них было не так, ну или кто-то сильно преувеличивает сложность отслеживания изменений формата.
С другой стороны, жалобы на "законодательство поменялось, а в обновлении 1С это еще не учли" - регулярная боль типовых решений (независимо от страны и года наблюдения). Странно для 1С лоббировать изменения, а потом "подставлять" своих клиентов.
Так что мое замечание было скорее про "а точно там были инсайды, или кто-то объясняет свою объективную неспособность успевать за изменениями, недобросовестной конкуренцией" ?
Можно писать код на английском (в т.ч. у вендора есть некоторое количество конфигураций для международного рынка, с мультиязычностью и кодом на латинице). Просто исторически, на постсоветском пространстве, код писали и пишут на русском (у этого есть бонус в виде совпадения терминов предметной области и сущностей / методов в коде).
Не могу уверенно говорить про РФ, но я в Беларуси сказки про "специальный формат для 1с" тоже регулярно слышал (и до сих пор слышу). Даже в местных приложениях для получения и отправки платежек в банк была кнопка "выгрузить в формате 1С". Сей "закрытый, инсайдерский, обфусцированный" формат, на практике был текстовым файлом (*.ini) с полной документацией по каждому полю и правилам заполнения. И назывался он так, только для того, чтобы тетушки-бухгалтера не путались, какую кнопку нажимать.
Простите, вы разработчику платформы (языка / библиотеки / фреймворка) предъявляете претензию за неработающую кнопку в каком-то кастомном решении на ней, написанном криворуким программистом?
В защиту автора могу сказать, что, к сожалению, на текущем месте работы мне подобных мероприятий сильно не хватает, и при выборе "получить в этом году прибавку" или "с этого года у нас будут вменяемые и работающие процессы разработки/онбординга/обмена опытом", я выбрал бы второе.
Как раз отличный пример. Потому что зафиксированное время - просто один из объективных фактов. А вот интерпретация этого факта (да еще и с выборочным учетом или не учетом контекста и других объективных фактов...) про "... - мудак, а остальные приходят..". Может Иванов ушел домой на час позже, а Сидоров и Петров после обеда в карты резались. Может он накануне за Ивановым и Петровым говнокод разгребал всю ночь, а под утро вырубился и проспал. И так далее. И это я еще не пытаюсь даже влезть в вопросы "а что происходит в другие дни?" и "а может быть у него вне работы что-то случилось?" (не говоря уж про бытовуху типа пробок).
"1C-программисты" это такой зонтик, под которым находятся совершенно разные люди:
Разработчики типовых и отраслевых коробочных решений внутри самой 1С + в фирмах партнерах (как правило, это именно разработчики, но с хорошим знанием предметки)
Собственно, упомянутые ниже внедренцы/консультанты/сопровождение (тут может быть в разных пропорциях намешан бизнес-анализ, разработка, кастомизация и просто установка обновлений)
Штатные сотрудники компаний, в которых используются системы на 1С (тут вообще под словом "1с-программист" могут понимать что угодно, как поддержку чужих решений, так и разработчики какого-то внутреннего проекта).
Есть люди, которые специализируются на вопросах производительности 1С-систем (с уклоном в DBA). и т.д.
Т.е. ответ "нет, не всегда это просто кастомизировал и свободен". Сейчас все чаще наблюдаю уход от "Вася на все руки мастер, и 1С настроит, и сервер, и принтер", к нормальным командам и процессам (с выделенными QA и BA, с современными процессами и технологиями).
Это не более чем вопрос привычки. Т.е. мне, допустим, комфортно читать код на английском, если это не 1С (мысленно на русский при этом не перевожу), а вот читать код 1С на английском - "ломает" (этакий своеобразный "эффект зловещей долины" только для программирования - мозг понимает, что это 1С, но какой-то неправильный =)).
Я вас вполне понимаю =) Меня это решение в MS Excel тоже всегда удивляло. У 1С, кстати, с этим проблем чуток поменьше - т.е. английский и русский можно (в случае с всякими "ФабрикаXDTO", к сожалению, иногда и нужно) смешивать, и вроде с большего работает нормально, хотя и не без косяков.
И вы только что точно описали причину, по которой большинство решений на 1С было написано на русском, при наличии англоязычных вариантов ключевых слов.
Тут скорее претензии к преподавателю, т.к. для учебных задач вполне можно было бы и на английском писать (благо есть даже статьи и видеокурс на курсере той же).
Уже полтора года прошло с вашей хвалебной статьи о LS Fusion (ну та, где "отличная система, гораздо лучше чем 1С, отличное описание в маркетинговых описаниях, надо будет на днях попробовать скачать и установить"). Может настало время все-таки скачать и посмотреть? =)
Это специфическая проблема ТСа. Он регулярно находит "гениальные" решения придуманных им проблем, игнорируя решения "общепринятые", просто раньше это не выходило за рамки 1С-форумов.
Только при этом придется еще и типовой код переписывать и в будущем все его изменения самостоятельно поддерживать. А в этом случае уже все равно - есть возможность подписаться или нет.
Платформа позволяет подписаться на: 1) запись всего объекта в БД 2) на интерактивное изменение значения в поле, которое связано со свойством объекта (в контексте формы), но ни один ни второй вариант не решат проблему @Naf2000.
В комментарии описана ситуация часто возникающая при доработке уже существующего решения, в котором часть полей объекта недоступна для изменения пользователем, а пересчитывается/заполняется на основании значений других полей.Причем реализовано авторами решения это может быть так, что этот пересчет происходит только при интерактивном тыканьи кнопок на форме, а если нужно, например, программно поменять/создать объекты (импорт из другой системы, к примеру), приходится этот код дублировать.
Собственно, наличие событий изменений свойств само по себе проблему тоже не решит - упрется в то, что нужно будет или переписывать логику типового решения, либо ждать пока это сделает сам вендор.
Можно, но мешать оба варианта синтаксиса в пределах одной конфигурации .. зачем?
Предположу, что претензии не к принципиальной невозможности что-то сделать (хотя надо всегда учитывать, что 99% 1С-ников, да и вообще разработчиков, работают с кем-то до них придуманной архитектурой решения, и любые попытки привнести "свежий взгляд" могут нарваться на суровую реальность легаси и/или непонимания коллег), а к синтаксическому сахару и удобству отладки / сопровождения.
P.S. Если не путаю, то в библитеке БПО на автоматически подключаемых расширениях построена работа с торговым оборудованием, когда в основной конфигурации есть только пустые экспортные методы, а их поведение определяется текущим подключенным расширением. Задачу конечно решает, и даже в некоторой степени "элегантно", но это как предлагать сменить C на ASM с макросами. Слишком много секса в гамаке на лыжах. Хотя со временем обрастаешь готовым кодом, набиваешь руку, нарабатываешь подходы, и вот уже все это не кажется странным, и без лыж и гамака даже удовольствие кажется не тем.
Опять же, делая скидку на реалии другой страны, в те времена когда я этим занимался, часто бывало, что импорт/экспорт при измениях в формате файлов я делал раньше, чем он официально появлялся в поставках местных франчайзи (в т.ч. у оф. представительства 1С). Значит что-то с инсайдами у них было не так, ну или кто-то сильно преувеличивает сложность отслеживания изменений формата.
С другой стороны, жалобы на "законодательство поменялось, а в обновлении 1С это еще не учли" - регулярная боль типовых решений (независимо от страны и года наблюдения). Странно для 1С лоббировать изменения, а потом "подставлять" своих клиентов.
Так что мое замечание было скорее про "а точно там были инсайды, или кто-то объясняет свою объективную неспособность успевать за изменениями, недобросовестной конкуренцией" ?
Можно писать код на английском (в т.ч. у вендора есть некоторое количество конфигураций для международного рынка, с мультиязычностью и кодом на латинице). Просто исторически, на постсоветском пространстве, код писали и пишут на русском (у этого есть бонус в виде совпадения терминов предметной области и сущностей / методов в коде).
Не могу уверенно говорить про РФ, но я в Беларуси сказки про "специальный формат для 1с" тоже регулярно слышал (и до сих пор слышу). Даже в местных приложениях для получения и отправки платежек в банк была кнопка "выгрузить в формате 1С". Сей "закрытый, инсайдерский, обфусцированный" формат, на практике был текстовым файлом (*.ini) с полной документацией по каждому полю и правилам заполнения. И назывался он так, только для того, чтобы тетушки-бухгалтера не путались, какую кнопку нажимать.
Коллеги там с помощью тест-центра запускают 400 сеансов, если что.
Простите, вы разработчику платформы (языка / библиотеки / фреймворка) предъявляете претензию за неработающую кнопку в каком-то кастомном решении на ней, написанном криворуким программистом?
В защиту автора могу сказать, что, к сожалению, на текущем месте работы мне подобных мероприятий сильно не хватает, и при выборе "получить в этом году прибавку" или "с этого года у нас будут вменяемые и работающие процессы разработки/онбординга/обмена опытом", я выбрал бы второе.
Как раз отличный пример. Потому что зафиксированное время - просто один из объективных фактов. А вот интерпретация этого факта (да еще и с выборочным учетом или не учетом контекста и других объективных фактов...) про "... - мудак, а остальные приходят..". Может Иванов ушел домой на час позже, а Сидоров и Петров после обеда в карты резались. Может он накануне за Ивановым и Петровым говнокод разгребал всю ночь, а под утро вырубился и проспал. И так далее. И это я еще не пытаюсь даже влезть в вопросы "а что происходит в другие дни?" и "а может быть у него вне работы что-то случилось?" (не говоря уж про бытовуху типа пробок).
"1C-программисты" это такой зонтик, под которым находятся совершенно разные люди:
Разработчики типовых и отраслевых коробочных решений внутри самой 1С + в фирмах партнерах (как правило, это именно разработчики, но с хорошим знанием предметки)
Собственно, упомянутые ниже внедренцы/консультанты/сопровождение (тут может быть в разных пропорциях намешан бизнес-анализ, разработка, кастомизация и просто установка обновлений)
Штатные сотрудники компаний, в которых используются системы на 1С (тут вообще под словом "1с-программист" могут понимать что угодно, как поддержку чужих решений, так и разработчики какого-то внутреннего проекта).
Есть люди, которые специализируются на вопросах производительности 1С-систем (с уклоном в DBA). и т.д.
Т.е. ответ "нет, не всегда это просто кастомизировал и свободен". Сейчас все чаще наблюдаю уход от "Вася на все руки мастер, и 1С настроит, и сервер, и принтер", к нормальным командам и процессам (с выделенными QA и BA, с современными процессами и технологиями).
Это не более чем вопрос привычки. Т.е. мне, допустим, комфортно читать код на английском, если это не 1С (мысленно на русский при этом не перевожу), а вот читать код 1С на английском - "ломает" (этакий своеобразный "эффект зловещей долины" только для программирования - мозг понимает, что это 1С, но какой-то неправильный =)).
Я вас вполне понимаю =) Меня это решение в MS Excel тоже всегда удивляло.
У 1С, кстати, с этим проблем чуток поменьше - т.е. английский и русский можно (в случае с всякими "ФабрикаXDTO", к сожалению, иногда и нужно) смешивать, и вроде с большего работает нормально, хотя и не без косяков.
И вы только что точно описали причину, по которой большинство решений на 1С было написано на русском, при наличии англоязычных вариантов ключевых слов.
Тут скорее претензии к преподавателю, т.к. для учебных задач вполне можно было бы и на английском писать (благо есть даже статьи и видеокурс на курсере той же).
Для MESSAGE expression это тоже работает, верно? Вроде бы в документации это явно не отражено.
Уже полтора года прошло с вашей хвалебной статьи о LS Fusion (ну та, где "отличная система, гораздо лучше чем 1С, отличное описание в маркетинговых описаниях, надо будет на днях попробовать скачать и установить"). Может настало время все-таки скачать и посмотреть? =)
Это специфическая проблема ТСа. Он регулярно находит "гениальные" решения придуманных им проблем, игнорируя решения "общепринятые", просто раньше это не выходило за рамки 1С-форумов.
".... — Мудрый филин, а как же мы станем ёжиками?
И ответил филин:
— Ребята, вы меня ерундой не грузите. Я стратегией занимаюсь. "
Только при этом придется еще и типовой код переписывать и в будущем все его изменения самостоятельно поддерживать. А в этом случае уже все равно - есть возможность подписаться или нет.
Платформа позволяет подписаться на: 1) запись всего объекта в БД 2) на интерактивное изменение значения в поле, которое связано со свойством объекта (в контексте формы), но ни один ни второй вариант не решат проблему @Naf2000.
В комментарии описана ситуация часто возникающая при доработке уже существующего решения, в котором часть полей объекта недоступна для изменения пользователем, а пересчитывается/заполняется на основании значений других полей.Причем реализовано авторами решения это может быть так, что этот пересчет происходит только при интерактивном тыканьи кнопок на форме, а если нужно, например, программно поменять/создать объекты (импорт из другой системы, к примеру), приходится этот код дублировать.
Собственно, наличие событий изменений свойств само по себе проблему тоже не решит - упрется в то, что нужно будет или переписывать логику типового решения, либо ждать пока это сделает сам вендор.