Хватит создавать формы выбора!
Комментарии
(3) konstruktiv,
Как мне кажется создавать одну форму списка и форму выбора не правильно с точки зрения подходов к разработке.
Это как с обработчиками событий. Для каждого обработчика своя процедура. Так же и тут для каждой задачи своя форма. Как минимум путаницы будет меньше. Особенно если работаешь не один. И после тебя людям поддерживать и дорабатывать конфигурацию. И люди которые придут со стороны как минимум ожидают что это будут разные формы.
И что потом делать если вдруг надо изменить поведение формы списка, а поведение формы выбора оставить как есть... придётся делать две формы.
ИМХО не очень красивое решение...
Получается здесь какая-то неактуальная информация
Как мне кажется создавать одну форму списка и форму выбора не правильно с точки зрения подходов к разработке.
Это как с обработчиками событий. Для каждого обработчика своя процедура. Так же и тут для каждой задачи своя форма. Как минимум путаницы будет меньше. Особенно если работаешь не один. И после тебя людям поддерживать и дорабатывать конфигурацию. И люди которые придут со стороны как минимум ожидают что это будут разные формы.
И что потом делать если вдруг надо изменить поведение формы списка, а поведение формы выбора оставить как есть... придётся делать две формы.
ИМХО не очень красивое решение...
(4) TODD22, тут можно поспорить. Повторю публикацию - мне много раз приходилось убеждаться, что когда при выборе значения в поле ввода открывается такая же форма, как и при отображении списка - у пользователя возникает меньший дискомфорт. Он пользуется теми же приемами (например для отбора), что и при работе в форме списка. Колонки находятся на тех же местах, их ширина запомнена, ненужные для пользователя данные он сам выключил, условное оформление, которое он для себя настроил - схоранилось. А когда это две разных формы - то, например, добавлении реквизита или изменения запроса ДС для вывода доп. информации, приходится дорабатывать две формы, что влечет дублирование кода.
Как часто приходилось это делать? Понятно, что есть случаи типа отображения остатков и прочие особенности форм подбора. Но посчитайте по своим конфигурациям, сколько форм выбора по отображаемой информации дублируют формы списка. Или отображают меньше информации (которая бывает необходима)?
И что потом делать если вдруг надо изменить поведение формы списка, а поведение формы выбора оставить как есть... придётся делать две формы.
Как часто приходилось это делать? Понятно, что есть случаи типа отображения остатков и прочие особенности форм подбора. Но посчитайте по своим конфигурациям, сколько форм выбора по отображаемой информации дублируют формы списка. Или отображают меньше информации (которая бывает необходима)?
(6) Fragster,
ИМХО тут даже спорить не о чем.
Нужно придерживаться стиля применяемого в типовых...
А не придумывать свои велосипеды...
Так создание однотипных обработчиков событий то же ведёт к дублированию кода. Может тогда один обработчик начать делать?
А что приёмы в форме выбора и форме списка отличаются?
тут можно поспорить.
ИМХО тут даже спорить не о чем.
Нужно придерживаться стиля применяемого в типовых...
А не придумывать свои велосипеды...
влечет дублирование кода.
Так создание однотипных обработчиков событий то же ведёт к дублированию кода. Может тогда один обработчик начать делать?
Он пользуется теми же приемами (например для отбора), что и при работе в форме списка.
А что приёмы в форме выбора и форме списка отличаются?
(8) Fragster,
Ещё ни разу не видел раздражения пользователя на список формы и список выбора... Да так что бы раздражение вызывало что это две разные формы и нужно срочно переделать в одну.
А вот такие "неожиданные" решения ИМХО не правильно. Механизмы должны быть так сказать с ожидаемым поведением и очевидной реализацией, 1С в первую очередь открытая система.
Если везде и всегда используются две разные формы то наверное правильно делать так же. Чем придумывать свой велосипед.
Пусть даже это увеличивает трудоёмкость. Зато это понятно и очевидно.
вот именно - меньше разных контекстов, меньше раздражение кожи пользователя
Ещё ни разу не видел раздражения пользователя на список формы и список выбора... Да так что бы раздражение вызывало что это две разные формы и нужно срочно переделать в одну.
А вот такие "неожиданные" решения ИМХО не правильно. Механизмы должны быть так сказать с ожидаемым поведением и очевидной реализацией, 1С в первую очередь открытая система.
Если везде и всегда используются две разные формы то наверное правильно делать так же. Чем придумывать свой велосипед.
Пусть даже это увеличивает трудоёмкость. Зато это понятно и очевидно.
(9) TODD22, ну, у вас пользователи не настраивают условное оформление, видимо. Не настраивают ширину колонок, не выключают "лишние" для них.
Я посчитал, сколько у меня одинаковых форм и как часто приходится дорабатывать обе, и вывел для себя подобное решение. Например когда дополнительная связанная информация хранится в РС и данные в этом РС вдруг расширили доп. реквизитом, надо этот реквизит добавить в обе формы.
Естественно, данное решение не панацея. Я не призываю его применять вообще везде. Например брать и перепиливать вдоль и поперек объекты типовых конфигураций не следует. А вот провести анализ, понять, сколько же одинаковых форм у нас есть в конфигурации - бывает полезно.
Я посчитал, сколько у меня одинаковых форм и как часто приходится дорабатывать обе, и вывел для себя подобное решение. Например когда дополнительная связанная информация хранится в РС и данные в этом РС вдруг расширили доп. реквизитом, надо этот реквизит добавить в обе формы.
Естественно, данное решение не панацея. Я не призываю его применять вообще везде. Например брать и перепиливать вдоль и поперек объекты типовых конфигураций не следует. А вот провести анализ, понять, сколько же одинаковых форм у нас есть в конфигурации - бывает полезно.
(6) Fragster, Есть конечно и такие формы выбора и списка где одинаково все, но чаще наоборот форма списка раскрашенная , куча настроек быстрых отборов и т.д. А форма выбора минималистична, а порой ввод по строке вообще избавляет от формы выбора.А еще форма выбора очень часто открывается с программным отбором который не нужен списку, ну и так далее, если если если....
Поддержу (13) alyaev.a.v.
Решение с 1 формой не рекомендовал бы только из-за наложенных отборов. На форму списка почти всегда накладываются пользовательские отборы. При использовании этой формы как формы выбора мы рискуем:
- пересечь пользовательский отбор с "программным"
- ввести пользователя в заблуждение, не отобразив доступные для выбора элементы, скрытые пользовательскими отборами.
Хотя реализация с 1 формой встречается и в типовых конфигурациях 1С.
Решение с 1 формой не рекомендовал бы только из-за наложенных отборов. На форму списка почти всегда накладываются пользовательские отборы. При использовании этой формы как формы выбора мы рискуем:
- пересечь пользовательский отбор с "программным"
- ввести пользователя в заблуждение, не отобразив доступные для выбора элементы, скрытые пользовательскими отборами.
Хотя реализация с 1 формой встречается и в типовых конфигурациях 1С.
(14) Drak0n, да, с пользовательскими отборами косяк есть. Это один из самых спорных моментов, причем это спорный момент в архитекторе платформы, о который немало копий сломано на партнерском форуме. Сломать форму можно не только в данном случае, но и в случае разных форм. Например, если есть несколько полей, открывающих одну форму выбора с разной связью параметров выбора.
Вроде бы есть даже записанное пожелание у разработчиков 1с, чтобы снималось "использование" пользовательского отбора в случае пересечения фиксированных и пользовательских настроек.
Вроде бы есть даже записанное пожелание у разработчиков 1с, чтобы снималось "использование" пользовательского отбора в случае пересечения фиксированных и пользовательских настроек.
(7) TODD22, чувак, открой ЗУП 3.0!!! Это АДДДДДДДД. Там фильтров в форме выбора сотрудников (уволен, организация, подразделение, архивный) жесть скока. И может так случиться, что в форме выбора сотрудника нет, а в форме списка есть. И пользователь сходу не врубается, почему данные отличаются. Я молчу, что при выборе физ-лица они показывают формы выбора сотрудника.
Я с автором солидарен: одна форма, единая логика работы! Прячем "архивных" сотрудников, следовательно прячем их и там и там. Один справочник - одна форма со списком.
Я с автором солидарен: одна форма, единая логика работы! Прячем "архивных" сотрудников, следовательно прячем их и там и там. Один справочник - одна форма со списком.
(21) monkbest,
Запустил штук 10 зупов 3.0. Никаких проблем описанных тобой не было ни у одного пользователя с формами списков и выборов так что бы их нужно было переделать в одну форму.
чувак, открой ЗУП 3.0!!! Это АДДДДДДДД. Там фильтров в форме выбора сотрудников (уволен, организация, подразделение, архивный) жесть скока.
Запустил штук 10 зупов 3.0. Никаких проблем описанных тобой не было ни у одного пользователя с формами списков и выборов так что бы их нужно было переделать в одну форму.
Мы с самого начала отказались от идеи плодить лишние сущности. Только стандартный код при создании на сервере у нас немножко другой:
За нюанс с множественным выбором - спасибо.
ЭтаФорма.Элементы.Список.РежимВыбора = Параметры.РежимВыбора;
Если ЭтаФорма.Элементы.Список.РежимВыбора Тогда
ЭтаФорма.РежимОткрытияОкна = РежимОткрытияОкнаФормы.БлокироватьОкноВладельца;
КонецЕсли;
...Показать СкрытьЗа нюанс с множественным выбором - спасибо.
Не так давно тоже начал применять данный подход и столкнулся с двумя особенностями из-за которых перестал использовать данный способ:
1. Сохраняются все настройки формы (добавленные поля, пользовательский отбор, размещение элементов на форме). Добавил я как то в форму списка подчиненного владельцу пользовательский отбор по владельцу, так как на форме списка его не было по бизнес логике, и соответственно он сохранился и применялся в режиме выбора с установленным отбором по владельцу через Связи параметров выбора.
2. Если используется метод глобального контекста ПоказатьВводЗначения или ВвестиЗначение, то в открываемой форме режим выбора не устанавливается, в результате приходится дописывать параметр РежимВыбора в модуль менеджера в событие ОбработкаПолученияФормы при открытии формы выбора что не очень удобно. Не тестировал еще работу в режиме подбора в список значений, открываемый в отборе компоновки с видом сравнения "В списке" и т.п.
1. Сохраняются все настройки формы (добавленные поля, пользовательский отбор, размещение элементов на форме). Добавил я как то в форму списка подчиненного владельцу пользовательский отбор по владельцу, так как на форме списка его не было по бизнес логике, и соответственно он сохранился и применялся в режиме выбора с установленным отбором по владельцу через Связи параметров выбора.
2. Если используется метод глобального контекста ПоказатьВводЗначения или ВвестиЗначение, то в открываемой форме режим выбора не устанавливается, в результате приходится дописывать параметр РежимВыбора в модуль менеджера в событие ОбработкаПолученияФормы при открытии формы выбора что не очень удобно. Не тестировал еще работу в режиме подбора в список значений, открываемый в отборе компоновки с видом сравнения "В списке" и т.п.
(28) Спасибо за замечания!
1. Проблема понятна, обход делается в три строчки:
Если Параметры.РежимВыбора И Не ЗначениеЗаполнено(Параметры.КлючПользовательскихНастроек) Тогда
Параметры.КлючПользовательскихНастроек = "РежимВыбора";
Список.АвтоматическоеСохранениеПользовательскихНастроек = Ложь;
КонецЕсли;
добавлю это в публикацию.
2. Странно, видимо имеет место ошибка платформы в конкретном вашем релизе. У меня при ПоказатьВводЗначения Параметры.РежимВыбора = Истина. Проверял на релизе 8.3.8.2137, режим совместимости = не использовать.
1. Проблема понятна, обход делается в три строчки:
Если Параметры.РежимВыбора И Не ЗначениеЗаполнено(Параметры.КлючПользовательскихНастроек) Тогда
Параметры.КлючПользовательскихНастроек = "РежимВыбора";
Список.АвтоматическоеСохранениеПользовательскихНастроек = Ложь;
КонецЕсли;
добавлю это в публикацию.
2. Странно, видимо имеет место ошибка платформы в конкретном вашем релизе. У меня при ПоказатьВводЗначения Параметры.РежимВыбора = Истина. Проверял на релизе 8.3.8.2137, режим совместимости = не использовать.
Ещё ни разу не видел раздражения пользователя на список формы и список выбора...
У Вас еще все впереди, видимо :)
И после тебя людям поддерживать и дорабатывать конфигурацию. И люди которые придут со стороны как минимум ожидают что это будут разные формы.
Может стоит посмотреть в основные формы в конфигураторе?
Использование одной формы в место двух оправданно и с точки зрения разработчиков и точки зрения пользователей.
Для меня как для разработчика проще обслуживать одну и туже форму, особенно на сильно доработанных конфигурациях, и особенно на сложных формах. Если в форме 100500 отборов, и она находится в активной разработке, и в день приходит 15 "указивок" что и как изменить.
Например у меня форма документа заказ покупателя:
на форме колонки с текущим долгом, датой ближайшей отгрузки, статусом обеспечения и оплаты, менеджер видит только свои заказы, старший менеджер заказы своего отдела, руководить направления только заказы по своему направлению и еще 50 "если".
И ты еще одну задачу типа "если это младший менеджер, то что бы только не отгруженные", и все это надо сделать в двух СОВЕРШЕННО ОДИНАКОВЫХ ФОРМАХ, открывающихся в разных режимах...
С проблемой программных отборов при открытии формы в режиме выбора пока не сталкивался, но уверен что решение есть. Тоже программное :)
А с точи зрения пользователя - уже писали выше. Одни колонки, одно оформление.
(30)
при наличии отборов можно выключать "предопределенные" пользовательские настройки, и использовать отдельный ключ для "непредопределенных". Вторая часть есть в примере кода, первая часть (и для фиксированных настроек для сложногоотбора и для отбора при связи параметров выбора) используется, например в в форме списка документа "Задачи".
С проблемой программных отборов при открытии формы в режиме выбора пока не сталкивался, но уверен что решение есть. Тоже программное :)
при наличии отборов можно выключать "предопределенные" пользовательские настройки, и использовать отдельный ключ для "непредопределенных". Вторая часть есть в примере кода, первая часть (и для фиксированных настроек для сложногоотбора и для отбора при связи параметров выбора) используется, например в в форме списка документа "Задачи".
Кстати, у 1С в типовых все тоже самое (немного видоизменен код в "ПриСозданииНаСервере" у формы списка), только никаких "нюансов" со множественностью выбора, работает и без этого:
Подозреваю, что код статьи подсмотрен через партнерский форум в типовых, т.к. навряд ли 1С использовала данный материал в своих разработках ))
Если Параметры.РежимВыбора Тогда
Элементы.Список.РежимВыбора = Истина;
КонецЕсли;
Подозреваю, что код статьи подсмотрен через партнерский форум в типовых, т.к. навряд ли 1С использовала данный материал в своих разработках ))
Прикрепленные файлы:
