Возможно ли передать параметр через промежуточный Объект?

Статус
В этой теме нельзя размещать новые ответы.

Ренат

Продвинутый
Доброго дня.
Передающий-принимающий параметр это очень удобно.
Но возникает вопрос, возможно ли передать параметр через промежуточный объект? (вопрос основа на версии Руна 5).
Изначальная задача: создается Объект, назовем его "Приложение", который фактически является списком документов. И одну и туже запись из данного Объекта хочется использовать в подчиненных списках различных иных объектов (чтобы не переписывать название документа снова).
Таким образом, Объект "Приложение" назначается подчиненным к различным Объектам, в частности: "Документы", "Акт приема-передачи", "Почта".
Для понимания, задача объектов "Документы" - формирование каких-то документов приложением в которых выступают записи из "Приложение". Задача "Акта приема-передачи" - формирование акта приема-передачи, в котором фигурирует перечень документов из "Приложение". Задача Объекта "Почта" - формирование почтовых отправлений с описью вложения, в описи фигурируют всё те же документы из объекта "Приложение".
Всё вроде бы просто, если только объект "Документы", не предполагает наличие нескольких подчиненных объектов, берущих свое начало из одного Объекта "Приложение".
Поскольку назначить в качестве подчиненного Объект можно только один раз, мы данную ситуацию исправляем как:
Создаем самостоятельные объекты, условные названия "Приложение 1", "Приложение 2", и т.п., с главным полем "Ссылка на объект" - "Приложение".
Таким образом, при формировании подчиненного списка "Приложение 1", мы фактически берем значения записей из Объекта Приложение. Аналогично в отношении подчиненного списка "Приложение 2", при этом наименование значений - может повторяться.
Далее мы создаем Объект "Приложение почта", главным полем которого является ссылка на объект Приложение.
Таким образом, вписав один раз значение в Объект "Приложение", у нас появляется возможность использования этой записи в подчиненных списках различных иных Объектов (не дублируя запись).
Для того чтобы разобраться во всем этом, мы также делаем Объект "Заказчики", на который ссылаются поле-ссылка из Детализаций всех вышеперечисленных Объектов.
Но со временем количество записей в объекте "Приложение" - становиться много и разобраться что к чему относиться - не реально (каждый раз смотреть на "Заказчика" - не удобно, да и в отношении одного и того же Заказчика имеются различные записи в одном Объекте.
Для выборки используем дополнительные поля (например активируем ссылочные поля - поля с Тильдой "~" - которые появились когда мы устанавливали подчиненные связи).
Но задача усложнена тем, что нам надо заполнять фильтр в крайнем объекте - "Приложение", это контрпродуктивно, при условии, что в первоначальных объектах, у нас имеется ссылочное поле на объект который повторяется во всех иных объектах (Объект "Заказчик").

Понимаю, что запутано, но всё же.
Таким образом, мы имеем ситуацию, когда из Одного объекта нам надо перед переход по Объекту найти искомую запись. И вот тут передать параметр из первоначального Объекта в конечный - мы не можем - только в ручную устанавливая значение соответствующего поля в переходном Объекте.
Возможна ли реализация поставленной задачи (передача параметра через проходной - не главный - Объект)?
Допускаю, что это реализовано в 6-й версии, тогда прошу прощение за то, что отвлек.
Возможно есть иные идеи, может я слишком усложняю задачу и например нет необходимости создавать промежуточный Объект - для этого существует более легкий способ: формирования нескольких подчиненных списков которые берут свое значение из одного и того же Объекта.
Формирование равнозначных связей мне не подходит, поскольку я хочу иметь возможность создания через интерфейс подчиненного списка - записей в подчиненном Объете.
Заранее благодарю за ответ.
 

Vladimir

Администратор
Команда форума
Добрый день, Ренат.
Насколько нам получилось понять - первоначальная проблема заключается в том, что в форме связи нельзя добавить "нескольких подчиненных списков которые берут свое значение из одного и того же Объекта"? И уже исходя из этого ограничения, Вы создаёте промежуточные объекты, что не даёт использовать передачу параметров.
Вопрос: если разрешить добавление нескольких подчинённых списков на базе одного объекта - поможет ли это решить задачу?
 

Ренат

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

Vladimir

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

Ренат

Продвинутый
Доброго дня. Спасибо, за проявленный интерес к доработке.
Однако, с учетом того, что эта доработка усложняет иной запланированный механизм, рекомендую рассмотреть вопрос доработки передающего параметра. По моему НЕ компетентному мнению, эта доработка должна быть более простой.
Не знаю насколько я прав с точки зрения программиста, но например можно ввести возможность назначения нескольких объектов с тильдой (я понимаю принцип когда поле с тильдой в подчиненном Объекте автоматически принимает значение соответствующее записи родительского объекта и понимаю почему в этом случае иные поля с тильдой не принимают автоматическое значение (они же подчинены иному родительскому объекту).
Но что если подумать о возникновении подобной возможности, т.е. рассмотреть возможность автоматического приобретения значения несколькими полями с тильдами. (информацию о ситуации когда один и тот же Объект одновременно подчиняется нескольким родительским объектам (что приводит к возникновению нескольких полей с тильдами) я встречал и в описаниях проектов иных Форумчан).
или может создать особый вид поля единственной функцией которого было бы передача параметра (не знаю как правильно описать идею, но: допустим в промежуточном объекте мы вставляем это особое поле которое принимает свое значение от определенного поля в родительском объекте, параллельно с полем с тильдой (появилось в момент подчинения). И это особое поле передает свое значение полю принимающему параметр)
Кстати пока писал возник вопрос: не существует ли уже сейчас возможности скопировать в поле ссылка на объект значение поля ссылка на объект родительского объекта. Тогда мы бы уже сейчас получили следующую реализацию: переходим в промежуточный объект в котором есть три поля: 1) поле с тильдой - принимает значение родительского объекта - ключевое поле; 2) поле ссылка на объект которое принимает свое значение путем копирования из поля ссылка на объект (не ключевое - расположено где то в Детализации); 3) поле ссылка на объект значение которого мы хотим выбрать из иного объекта. При выборе значения поля № 3, значения полей 1 и 2 передаются в фильтр.
Завтра постараюсь посмотреть существует ли такая возможность, тогда необходимость в доработке - отпадет.
 

Vladimir

Администратор
Команда форума
Добрый день, Ренат.
Очень радует, что Вы так серьёзно постарались найти решение для своей задачи. Нечасто люди стараются глубже понять идею конструктора и предложить интересную идею в развитие программы.
Ваше предложение заставило нас гораздо серьёзнее задуматься над возникшей задачей. Когда возникают подобные вопросы (а чаще они возникают у нас), то мы стараемся не просто реализовать прямое решение в виде дополнительного инструмента, а найти связующий элемент (задействовать уже существующий или дополнить новым), который впишется в общую идею.
Поставленный Вами вопрос коснулся темы дочерних списков в форме связи. Создание такого списка в программе было реализовано простым добавлением поля ссылки на родительский объект в дочернем объекте - вот и весь механизм дочерних объектов. Просто до безобразия. Но в силу того, что поле ссылки на объект создаётся не самим пользователем, а программой (в автоматическом режиме), иногда человеку довольно сложно понять что происходит в программе и как оно работает. Поле ссылки, которое создаётся системой автоматически и используется для формы связи, визуально выделяется серым цветом и помечается тильдой в префиксе, но это не улучшает понимание его работы.

На будущее мы планировали изменить принцип работы связующего поля: если поля нет, то создавать его как и раньше (но убрать выделение серым цветом и добавление тильды). А если поле ссылки на родительский объект есть, то использовать уже его. Такое изменение требовалось бы для того, чтобы проще менять уже существующую структуру проекта, когда надо создать форму связи, а поле ссылки уже есть.
Например есть база данных с марками и моделями автомобиля. Для модели есть ссылка на марку и база уже заполнена. Человек решает создать форму связи, где выбирая марку - будет видеть все привязанные к ней модели. При создании формы связи на базе марки авто, в объекте модели автоматически создаётся поле ссылки на объект марки. При этом остаётся висеть пользовательское поле ссылки на объект марки. Чтобы перебить данные, надо либо вручную (сделав видимым поле ссылки) перевыбрать данные в каждой записи, либо воспользоваться экспортом/импортом через файл .csv (что тоже требует определённых временных затрат).

Идея использования одного объекта в качестве нескольких дочерних списков в форме связи имеет место быть. Подобные Вашей задаче уже встречались нам, но красивого решения до сего дня не находилось. Плюс те нюансы, которые описал выше, и некоторые другие, внутренние.

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