9thlevel4 мар 2014 в 11:42

Гибкое управление свойствами доступности элементов управления в обычных формах 1С: Предприятия 8.х

7 мин

41K

Программирование * Веб-разработка *

Из песочницы

Комментарии 26

Fragster 4 мар 2014 в 12:46

Если уж копрокодить, то почему не так (ну, или подобно)?

Функция ПолучитьЭлементУправленияПоИмени(Форма, Знач ИмяЭлемента)
    Перем ЭлементУправления;
    Попытка
        ЭлементУправления = Вычислить("Форма.ЭлементыФормы."+ИмяЭлемента);
    Исключение
    КонецПопытки;
    Возврат ЭлементУправления;
КонецФункции

9thlevel 4 мар 2014 в 13:06

Критикуете? Предложите свой вариант управления элементами. С удовольствием изучу Ваш опыт.

Fragster 4 мар 2014 в 13:19

Поясните необходимость дополнительного уровня абстракции? Если же необходимость в этом уровне есть, то почему не объединены все списки в одну таблицу?

Зачем там «Попытка» (которую я в свой код скопировал, пытаясь указать на лишний цикл)? Почему при неправильном коде (например при удалении элемента управления или опечатки) программа не должна падать?

9thlevel 4 мар 2014 в 13:31

Если же необходимость в этом уровне есть, то почему не объединены все списки в одну таблицу?

Лично я руководствуюсь принципом «все сваливать в кучу не стоит». Что можно разделить, то нужно разделить. Сугубо мое мнение.

Зачем там «Попытка» (которую я в свой код скопировал, пытаясь указать на лишний цикл)? Почему при неправильном коде (например при удалении элемента управления или опечатки) программа не должна падать?

Потому что бизнес-процесс (особенно процесс торговли) не должен прерываться ошибками. Оперативно устранить не всегда бывает возможно. А чтобы не падали программы, их нужно тестировать. Хотя бы по-минимуму.

Fragster 4 мар 2014 в 13:45

Так зачем там этот уровень абстракции?

Потому что бизнес-процесс (особенно процесс торговли) не должен прерываться ошибками. Оперативно устранить не всегда бывает возможно. А чтобы не падали программы, их нужно тестировать. Хотя бы по-минимуму.

Так вы не тестируете, прежде чем накатывать обновление на рабочую базу? А то, что там куча исключений, о которых вы без падений и не узнаете, а пользователи будут молчать о том, что галочка «Наличная продажа» не влияет на видимость галочки «Пробивать чек», ведь ни не знают о том, что так должно быть?

9thlevel 4 мар 2014 в 13:52

Так зачем там этот уровень абстракции?

Там — это где?

Так вы не тестируете, прежде чем накатывать обновление на рабочую базу?

А вы сами как думаете?

А то, что там куча исключений, о которых вы без падений и не узнаете, а пользователи будут молчать о том, что галочка «Наличная продажа» не влияет на видимость галочки «Пробивать чек», ведь ни не знают о том, что так должно быть?

Пользователи должны работать, а не ошибки искать.

Fragster 4 мар 2014 в 14:00

Так зачем там этот уровень абстракции?
Там — это где?

В управлении доступностью и видимостью

А вы сами как думаете?

Думаю, что код вида

Попытка 
  //Код
Исключение
  //молчим
КонецПопытки

негативно влияет на тестирование, а попытка нужна для того, чтобы в случае ошибки (причем только по независящим от программиста причинам, например отсутствие доступа к внешнему ресурсу) что-то с ней сделать (например попробовать еще раз с другим ресурсом или собрать информацию об ошибке и преобразовать её к виду, нужному для техподдержки и остановить выполнение)

9thlevel 4 мар 2014 в 14:08

В управлении доступностью и видимостью

Чтобы лучше понимать, что происходит, когда происходит и с чем происходит. Да-да, какой вопрос, такой ответ :)

Думаю, что код вида… негативно влияет на тестирование, а попытка нужна для того, чтобы в случае ошибки (причем только по независящим от программиста причинам, например отсутствие доступа к внешнему ресурсу) что-то с ней сделать (например попробовать еще раз с другим ресурсом или собрать информацию об ошибке и преобразовать её к виду, нужному для техподдержки и остановить выполнение)

Не буду вас отговаривать от вашего мнения. Только когда в команде 5 и более разработчиков, и время от времени каждый хоть один раз, но что-то изменяет на форме (особенно «новобранцы»), бывает это спасает.

EvilBeaver 5 мар 2014 в 11:43

Так вы не тестируете, прежде чем накатывать обновление на рабочую базу? А то, что там куча исключений, о которых вы без падений и не узнаете

Это очень распространенный workflow в сфере допиливания 1С. Заверни в «попытку», чтобы не было сообщений. Пользователю знать это не надо, ему надо чтобы не падало. Практика порочная, но в уравнении время-деньги-качество играет немаленькую роль.
Приходится много сил тратить, чтобы убедить разработчиков так не делать. Видимая ошибка лучше спрятанной.

9thlevel 5 мар 2014 в 12:52

Это очень распространенный workflow в сфере допиливания 1С. Заверни в «попытку», чтобы не было сообщений. Пользователю знать это не надо, ему надо чтобы не падало. Практика порочная, но в уравнении время-деньги-качество играет немаленькую роль.
Приходится много сил тратить, чтобы убедить разработчиков так не делать. Видимая ошибка лучше спрятанной.

Я понимаю, что существует «свое мнение и мнение остальных». Но данная моя статья не претендует на «идеальный код» и «идеальный пост». Опубликована она была с целью помочь кому-либо, бескорыстно. Может кому-то она подскажет решение, может кому-то окажется полезной. Кому-то окажется бесполезной, это тоже возможно. Но! Я с уважением отношусь к хабрасообществу, но частенько попадаются комментарии людей которые все могут и все умеют. Критикуете? Предлагайте.

Flyd 5 мар 2014 в 13:26

Я бы предложил навести порядок с разработкой, тестированием и накатыванием обновлений. Поскольку когда 5 разработчиков могут независимо друг от друга вносить изменения в одну и ту же форму и каждый может внести такое обновление, которое всё порушит это как-то ненормально

9thlevel 5 мар 2014 в 22:27

Я бы предложил навести порядок с разработкой, тестированием и накатыванием обновлений. Поскольку когда 5 разработчиков могут независимо друг от друга вносить изменения в одну и ту же форму и каждый может внести такое обновление, которое всё порушит это как-то ненормально.

Согласен, это ненормально. Вы знаете, я пытался. Но поскольку не являюсь руководителем, мои предложения уходят в космос. Есть еще куча нюансов, но они внутрикорпоративные. Это мое маленькое пояснение. Без дальнейшего развития и продолжения обсуждения :)

Adnako 4 мар 2014 в 13:16

Т.е. когда какой-то сферический флажок логически связан с, например, видимостью одного элемента формы, то при вызове УстановитьДоступ() всё равно будут рассчитаны остальные связи и установлены не изменившиеся значения?
На мой взгляд именно эта проблема как раз более интересна — как универсально и удобно вычислять только необходимые изменения на форме.

9thlevel 4 мар 2014 в 13:37

Adnako, думал об этом :) Несколько идей и наработок есть, в тестовом режиме использую у себя их. Но это мой первый пост на Хабре. Если не «распнут», напишу вторую часть.

Adnako 4 мар 2014 в 13:40

Ну тогда, ждём продолжения. Reactive1C не жду, конечно, но вдруг что-то новое засветится :)

Asmody 4 мар 2014 в 14:40

подобие reactive1C можно реализовать на обработчиках изменения данных, если я правильно понял вашу мысль

Adnako 4 мар 2014 в 14:46

Если «обработчики изменения данных» это события на форме, то получить работающий Reactive1C невозможно — насколько я помню — программные изменения данных не вызывают, или не всегда вызывают, эти обработчики, увы.

leemuar 4 мар 2014 в 17:42

Вы правильно помните. Обработчики вызываются только при интерактивной работе на форме, они для этого и задуманы. Предполагается, что если что-то меняется программно, то эти изменения вносит грамотный человек с расширенными полномочиями (возможность изменять программный код), понимающий что он делает, поэтому его контроль обработчиками не нужен

Asmody 4 мар 2014 в 18:41

Я ж написал «подобие». В любом случае, и статья, и обсуждение — это попытка догнать вчерашний день. Про обычные формы уже года два даже говорить неинтересно.

YuriyM 4 мар 2014 в 19:05

Можно Вас поздравить с изобретением еще одной машины состояний (State machine)…

EvilBeaver 5 мар 2014 в 08:36

Если мне не изменяет память, то делать перепосты с других сайтов запрещено правилами.
infostart.ru/public/262631/
И не стыдно вам?

9thlevel 5 мар 2014 в 12:47

Уважаемый, я вынужден вас попросить извиниться за непроверенное обвинение. Если вы внимательно посмотрите имя автора поста, который вы привели (http://infostart.ru/public/262631/), и имя, которое скрывается под моим ником 9thlevel, то убедитесь, что это один и тот же человек. То есть я. И эту же свою статью я опубликовал в своем блоге вот тут: http://zhilichev.blogspot.com. Прошу перейти и убедиться. Жду извинений.

EvilBeaver 5 мар 2014 в 13:32

Я видел, что автор один и тот же. Я нигде не говорил, что эта статья — плагиат.
В правилах сказано:

Хабр — не ЖЖ и не центр мирового кросспостинга. Не нужно копировать посты из других блогов и сайтов, указывая, что ранее они были опубликованы в другом месте.

Я понимаю, что это, скорее, рекомендация, чем жесткий закон, но тем не менее, кросс-посты с «Инфостарта» кажутся мне немного некорректными. У меня и у самого на «Инфостарте» ряд статей, но постить их сюда показалось неуместным. Тем более, что какой-то инженерной новизны в вашем решении не сильно заметно.
Все вышесказанное — мое личное мнение и оно, разумеется, может быть оспорено. Я, действительно, скажу вам «извините», если задел слишком небрежным комментарием. Мнение мое остается неизменным — для не-1С-ников статья не несет интересных инженерных решений, а для 1С-ников статья слишком… как бы выразиться… банальная что-ли…

Если говорить о «критикуя — предлагай», то предлагать-то и нечего, задача довольно тривиальная, любое решение будет таким же «капитанским», как и ваше. У вас, как сказали выше — подобие машины состояний. При необходимости вызывается логика расстановки признаков видимости и доступности, затем меняются свойства формы. Кардинального преимущества перед установкой этих свойств «в лоб» я что-то не вижу.

Возможно, я просто тупой и не понимаю чего-то в вашей статье. В таком случае, держите еще одно извинение, но поясните тогда мне, в чем состоит инженерная новизна (красота, если угодно) предлагаемого вами решения?

9thlevel 5 мар 2014 в 22:18

Возможно, я просто тупой и не понимаю чего-то в вашей статье. В таком случае, держите еще одно извинение, но поясните тогда мне, в чем состоит инженерная новизна (красота, если угодно) предлагаемого вами решения?

Почему вы ищите инженерной новизны? И полезность, насколько я понял, рассматриваете по отношению к себе. На текущий момент пост добавили к себе в избранное 19 человек. Им он оказался полезен. Помните такое выражение «И если из трех тысяч, меня один услышит, Поймет масштабы, значит вся идея дышит». Так вот, я не стремился показать, «как я крут». Я просто поделился наработкой. А где это разместил, это мое дело. Нет, не стыдно. Если вам не интересно и банально, проходите мимо. Серьезно.

EvilBeaver 6 мар 2014 в 06:01

Да, пожалуй мой скепсис был вызван тем, что я слишком многого ожидал. Прочитал первые 2 абзаца и заинтересовался — о, удобная система управления взаимосвязанными состояниями элементов в форме! Это же классная штука! Дочитал и ничего из того, что ожидал — не увидел. Разочаровался, да. Не узнал ничего полезного, а хотелось. По вашему совету, ухожу проходить мимо.

Dementor 13 мар 2014 в 16:44

Не понял в чем зерно рационализаторства и преимущества перед классическим подходом единой процедуры УстановитьВидимостьДоступность().

1) С точки зрения вычислительной техники появились дополнительные структуры данных и дополнительные вызовы ряда процедур, что ничтожно но все же увеличивает расход памяти и процессорного времени. Т.е. про оптимизацию кода мы вообще не говорим.

2) Иногда бизнес-логика довольно запутанная и нельзя обойтись банальным «если галочка есть, то элемент видим, а иначе — не видим». Иногда нужно анализировать несколько показателей, наложить на них значения параметров сеанса и сделать запрос к регистру а-ля «ДополнительныеПраваПользователей». Если в этом довольно распространенном случае нужно управлять не только видимостью, но еще и доступностью и «только просмотром» целого ряда элементов формы, то ваш вариант в разных процедурах требует дублирования одного и того же сложного кода (а следовательно и времени на его исполнения). И все это вместо один раз выполнить и применить результат к видимости-доступности сразу ряда элементов.

3) Банально от программиста требуется больше писать без возможности использования автокомплита. Вместо:

ЭлементыФормы.Комментарий.ТолькоПросмотр = не (НаличнаяПродажа И НЕ ДисконтнаяКарта.Пустая());

в вашей интерпретации теперь нужно:

ЗначениеРедактированиеТекста = НаличнаяПродажа И НЕ ДисконтнаяКарта.Пустая();
СписокУправлениеРедактированиемТекста.Добавить(ЗначениеРедактированиеТекста, "Комментарий");

4) Как уже упомянули в комментариях — этот «велосипед» совсем не годится для работы в управляемом режиме форм. Как только мы переходим на использование возможностей 8.2 и 8.3, так сразу ваши процедуры общих модулей начинают порождать лишние клиент-серверные вызовы и общее торможение на каждый чих.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий