Комментарии 26
Если уж копрокодить, то почему не так (ну, или подобно)?
Функция ПолучитьЭлементУправленияПоИмени(Форма, Знач ИмяЭлемента)
Перем ЭлементУправления;
Попытка
ЭлементУправления = Вычислить("Форма.ЭлементыФормы."+ИмяЭлемента);
Исключение
КонецПопытки;
Возврат ЭлементУправления;
КонецФункции
Критикуете? Предложите свой вариант управления элементами. С удовольствием изучу Ваш опыт.
Поясните необходимость дополнительного уровня абстракции? Если же необходимость в этом уровне есть, то почему не объединены все списки в одну таблицу?
Зачем там «Попытка» (которую я в свой код скопировал, пытаясь указать на лишний цикл)? Почему при неправильном коде (например при удалении элемента управления или опечатки) программа не должна падать?
Зачем там «Попытка» (которую я в свой код скопировал, пытаясь указать на лишний цикл)? Почему при неправильном коде (например при удалении элемента управления или опечатки) программа не должна падать?
Если же необходимость в этом уровне есть, то почему не объединены все списки в одну таблицу?
Лично я руководствуюсь принципом «все сваливать в кучу не стоит». Что можно разделить, то нужно разделить. Сугубо мое мнение.
Зачем там «Попытка» (которую я в свой код скопировал, пытаясь указать на лишний цикл)? Почему при неправильном коде (например при удалении элемента управления или опечатки) программа не должна падать?
Потому что бизнес-процесс (особенно процесс торговли) не должен прерываться ошибками. Оперативно устранить не всегда бывает возможно. А чтобы не падали программы, их нужно тестировать. Хотя бы по-минимуму.
Так зачем там этот уровень абстракции?
Так вы не тестируете, прежде чем накатывать обновление на рабочую базу? А то, что там куча исключений, о которых вы без падений и не узнаете, а пользователи будут молчать о том, что галочка «Наличная продажа» не влияет на видимость галочки «Пробивать чек», ведь ни не знают о том, что так должно быть?
Потому что бизнес-процесс (особенно процесс торговли) не должен прерываться ошибками. Оперативно устранить не всегда бывает возможно. А чтобы не падали программы, их нужно тестировать. Хотя бы по-минимуму.
Так вы не тестируете, прежде чем накатывать обновление на рабочую базу? А то, что там куча исключений, о которых вы без падений и не узнаете, а пользователи будут молчать о том, что галочка «Наличная продажа» не влияет на видимость галочки «Пробивать чек», ведь ни не знают о том, что так должно быть?
Так зачем там этот уровень абстракции?
Там — это где?
Так вы не тестируете, прежде чем накатывать обновление на рабочую базу?
А вы сами как думаете?
А то, что там куча исключений, о которых вы без падений и не узнаете, а пользователи будут молчать о том, что галочка «Наличная продажа» не влияет на видимость галочки «Пробивать чек», ведь ни не знают о том, что так должно быть?
Пользователи должны работать, а не ошибки искать.
Так зачем там этот уровень абстракции?Там — это где?
В управлении доступностью и видимостью
А вы сами как думаете?Думаю, что код вида
Попытка
//Код
Исключение
//молчим
КонецПопытки
В управлении доступностью и видимостью
Чтобы лучше понимать, что происходит, когда происходит и с чем происходит. Да-да, какой вопрос, такой ответ :)
Думаю, что код вида… негативно влияет на тестирование, а попытка нужна для того, чтобы в случае ошибки (причем только по независящим от программиста причинам, например отсутствие доступа к внешнему ресурсу) что-то с ней сделать (например попробовать еще раз с другим ресурсом или собрать информацию об ошибке и преобразовать её к виду, нужному для техподдержки и остановить выполнение)
Не буду вас отговаривать от вашего мнения. Только когда в команде 5 и более разработчиков, и время от времени каждый хоть один раз, но что-то изменяет на форме (особенно «новобранцы»), бывает это спасает.
Так вы не тестируете, прежде чем накатывать обновление на рабочую базу? А то, что там куча исключений, о которых вы без падений и не узнаете
Это очень распространенный workflow в сфере допиливания 1С. Заверни в «попытку», чтобы не было сообщений. Пользователю знать это не надо, ему надо чтобы не падало. Практика порочная, но в уравнении время-деньги-качество играет немаленькую роль.
Приходится много сил тратить, чтобы убедить разработчиков так не делать. Видимая ошибка лучше спрятанной.
Это очень распространенный workflow в сфере допиливания 1С. Заверни в «попытку», чтобы не было сообщений. Пользователю знать это не надо, ему надо чтобы не падало. Практика порочная, но в уравнении время-деньги-качество играет немаленькую роль.
Приходится много сил тратить, чтобы убедить разработчиков так не делать. Видимая ошибка лучше спрятанной.
Я понимаю, что существует «свое мнение и мнение остальных». Но данная моя статья не претендует на «идеальный код» и «идеальный пост». Опубликована она была с целью помочь кому-либо, бескорыстно. Может кому-то она подскажет решение, может кому-то окажется полезной. Кому-то окажется бесполезной, это тоже возможно. Но! Я с уважением отношусь к хабрасообществу, но частенько попадаются комментарии людей которые все могут и все умеют. Критикуете? Предлагайте.
Я бы предложил навести порядок с разработкой, тестированием и накатыванием обновлений. Поскольку когда 5 разработчиков могут независимо друг от друга вносить изменения в одну и ту же форму и каждый может внести такое обновление, которое всё порушит это как-то ненормально
Я бы предложил навести порядок с разработкой, тестированием и накатыванием обновлений. Поскольку когда 5 разработчиков могут независимо друг от друга вносить изменения в одну и ту же форму и каждый может внести такое обновление, которое всё порушит это как-то ненормально.
Согласен, это ненормально. Вы знаете, я пытался. Но поскольку не являюсь руководителем, мои предложения уходят в космос. Есть еще куча нюансов, но они внутрикорпоративные. Это мое маленькое пояснение. Без дальнейшего развития и продолжения обсуждения :)
Т.е. когда какой-то сферический флажок логически связан с, например, видимостью одного элемента формы, то при вызове УстановитьДоступ() всё равно будут рассчитаны остальные связи и установлены не изменившиеся значения?
На мой взгляд именно эта проблема как раз более интересна — как универсально и удобно вычислять только необходимые изменения на форме.
На мой взгляд именно эта проблема как раз более интересна — как универсально и удобно вычислять только необходимые изменения на форме.
Adnako, думал об этом :) Несколько идей и наработок есть, в тестовом режиме использую у себя их. Но это мой первый пост на Хабре. Если не «распнут», напишу вторую часть.
Ну тогда, ждём продолжения. Reactive1C не жду, конечно, но вдруг что-то новое засветится :)
подобие reactive1C можно реализовать на обработчиках изменения данных, если я правильно понял вашу мысль
Если «обработчики изменения данных» это события на форме, то получить работающий Reactive1C невозможно — насколько я помню — программные изменения данных не вызывают, или не всегда вызывают, эти обработчики, увы.
Вы правильно помните. Обработчики вызываются только при интерактивной работе на форме, они для этого и задуманы. Предполагается, что если что-то меняется программно, то эти изменения вносит грамотный человек с расширенными полномочиями (возможность изменять программный код), понимающий что он делает, поэтому его контроль обработчиками не нужен
Я ж написал «подобие». В любом случае, и статья, и обсуждение — это попытка догнать вчерашний день. Про обычные формы уже года два даже говорить неинтересно.
Можно Вас поздравить с изобретением еще одной машины состояний (State machine)…
Если мне не изменяет память, то делать перепосты с других сайтов запрещено правилами.
infostart.ru/public/262631/
И не стыдно вам?
infostart.ru/public/262631/
И не стыдно вам?
Уважаемый, я вынужден вас попросить извиниться за непроверенное обвинение. Если вы внимательно посмотрите имя автора поста, который вы привели (http://infostart.ru/public/262631/), и имя, которое скрывается под моим ником 9thlevel, то убедитесь, что это один и тот же человек. То есть я. И эту же свою статью я опубликовал в своем блоге вот тут: http://zhilichev.blogspot.com. Прошу перейти и убедиться. Жду извинений.
Я видел, что автор один и тот же. Я нигде не говорил, что эта статья — плагиат.
В правилах сказано:
Я понимаю, что это, скорее, рекомендация, чем жесткий закон, но тем не менее, кросс-посты с «Инфостарта» кажутся мне немного некорректными. У меня и у самого на «Инфостарте» ряд статей, но постить их сюда показалось неуместным. Тем более, что какой-то инженерной новизны в вашем решении не сильно заметно.
Все вышесказанное — мое личное мнение и оно, разумеется, может быть оспорено. Я, действительно, скажу вам «извините», если задел слишком небрежным комментарием. Мнение мое остается неизменным — для не-1С-ников статья не несет интересных инженерных решений, а для 1С-ников статья слишком… как бы выразиться… банальная что-ли…
Если говорить о «критикуя — предлагай», то предлагать-то и нечего, задача довольно тривиальная, любое решение будет таким же «капитанским», как и ваше. У вас, как сказали выше — подобие машины состояний. При необходимости вызывается логика расстановки признаков видимости и доступности, затем меняются свойства формы. Кардинального преимущества перед установкой этих свойств «в лоб» я что-то не вижу.
Возможно, я просто тупой и не понимаю чего-то в вашей статье. В таком случае, держите еще одно извинение, но поясните тогда мне, в чем состоит инженерная новизна (красота, если угодно) предлагаемого вами решения?
В правилах сказано:
Хабр — не ЖЖ и не центр мирового кросспостинга. Не нужно копировать посты из других блогов и сайтов, указывая, что ранее они были опубликованы в другом месте.
Я понимаю, что это, скорее, рекомендация, чем жесткий закон, но тем не менее, кросс-посты с «Инфостарта» кажутся мне немного некорректными. У меня и у самого на «Инфостарте» ряд статей, но постить их сюда показалось неуместным. Тем более, что какой-то инженерной новизны в вашем решении не сильно заметно.
Все вышесказанное — мое личное мнение и оно, разумеется, может быть оспорено. Я, действительно, скажу вам «извините», если задел слишком небрежным комментарием. Мнение мое остается неизменным — для не-1С-ников статья не несет интересных инженерных решений, а для 1С-ников статья слишком… как бы выразиться… банальная что-ли…
Если говорить о «критикуя — предлагай», то предлагать-то и нечего, задача довольно тривиальная, любое решение будет таким же «капитанским», как и ваше. У вас, как сказали выше — подобие машины состояний. При необходимости вызывается логика расстановки признаков видимости и доступности, затем меняются свойства формы. Кардинального преимущества перед установкой этих свойств «в лоб» я что-то не вижу.
Возможно, я просто тупой и не понимаю чего-то в вашей статье. В таком случае, держите еще одно извинение, но поясните тогда мне, в чем состоит инженерная новизна (красота, если угодно) предлагаемого вами решения?
Возможно, я просто тупой и не понимаю чего-то в вашей статье. В таком случае, держите еще одно извинение, но поясните тогда мне, в чем состоит инженерная новизна (красота, если угодно) предлагаемого вами решения?
Почему вы ищите инженерной новизны? И полезность, насколько я понял, рассматриваете по отношению к себе. На текущий момент пост добавили к себе в избранное 19 человек. Им он оказался полезен. Помните такое выражение «И если из трех тысяч, меня один услышит, Поймет масштабы, значит вся идея дышит». Так вот, я не стремился показать, «как я крут». Я просто поделился наработкой. А где это разместил, это мое дело. Нет, не стыдно. Если вам не интересно и банально, проходите мимо. Серьезно.
Да, пожалуй мой скепсис был вызван тем, что я слишком многого ожидал. Прочитал первые 2 абзаца и заинтересовался — о, удобная система управления взаимосвязанными состояниями элементов в форме! Это же классная штука! Дочитал и ничего из того, что ожидал — не увидел. Разочаровался, да. Не узнал ничего полезного, а хотелось. По вашему совету, ухожу проходить мимо.
Не понял в чем зерно рационализаторства и преимущества перед классическим подходом единой процедуры УстановитьВидимостьДоступность().
1) С точки зрения вычислительной техники появились дополнительные структуры данных и дополнительные вызовы ряда процедур, что ничтожно но все же увеличивает расход памяти и процессорного времени. Т.е. про оптимизацию кода мы вообще не говорим.
2) Иногда бизнес-логика довольно запутанная и нельзя обойтись банальным «если галочка есть, то элемент видим, а иначе — не видим». Иногда нужно анализировать несколько показателей, наложить на них значения параметров сеанса и сделать запрос к регистру а-ля «ДополнительныеПраваПользователей». Если в этом довольно распространенном случае нужно управлять не только видимостью, но еще и доступностью и «только просмотром» целого ряда элементов формы, то ваш вариант в разных процедурах требует дублирования одного и того же сложного кода (а следовательно и времени на его исполнения). И все это вместо один раз выполнить и применить результат к видимости-доступности сразу ряда элементов.
3) Банально от программиста требуется больше писать без возможности использования автокомплита. Вместо:
в вашей интерпретации теперь нужно:
4) Как уже упомянули в комментариях — этот «велосипед» совсем не годится для работы в управляемом режиме форм. Как только мы переходим на использование возможностей 8.2 и 8.3, так сразу ваши процедуры общих модулей начинают порождать лишние клиент-серверные вызовы и общее торможение на каждый чих.
1) С точки зрения вычислительной техники появились дополнительные структуры данных и дополнительные вызовы ряда процедур, что ничтожно но все же увеличивает расход памяти и процессорного времени. Т.е. про оптимизацию кода мы вообще не говорим.
2) Иногда бизнес-логика довольно запутанная и нельзя обойтись банальным «если галочка есть, то элемент видим, а иначе — не видим». Иногда нужно анализировать несколько показателей, наложить на них значения параметров сеанса и сделать запрос к регистру а-ля «ДополнительныеПраваПользователей». Если в этом довольно распространенном случае нужно управлять не только видимостью, но еще и доступностью и «только просмотром» целого ряда элементов формы, то ваш вариант в разных процедурах требует дублирования одного и того же сложного кода (а следовательно и времени на его исполнения). И все это вместо один раз выполнить и применить результат к видимости-доступности сразу ряда элементов.
3) Банально от программиста требуется больше писать без возможности использования автокомплита. Вместо:
ЭлементыФормы.Комментарий.ТолькоПросмотр = не (НаличнаяПродажа И НЕ ДисконтнаяКарта.Пустая());в вашей интерпретации теперь нужно:
ЗначениеРедактированиеТекста = НаличнаяПродажа И НЕ ДисконтнаяКарта.Пустая();
СписокУправлениеРедактированиемТекста.Добавить(ЗначениеРедактированиеТекста, "Комментарий");4) Как уже упомянули в комментариях — этот «велосипед» совсем не годится для работы в управляемом режиме форм. Как только мы переходим на использование возможностей 8.2 и 8.3, так сразу ваши процедуры общих модулей начинают порождать лишние клиент-серверные вызовы и общее торможение на каждый чих.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Гибкое управление свойствами доступности элементов управления в обычных формах 1С: Предприятия 8.х