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

Имею связку master-detail. Связка осуществляется с использованием n_cst_dwsrv_linkage. Возник вопрос - а что делать, если параметры в retrieve для detail`а не ограничиваются только полем из мастера?

На всякий случай (а то придет Филипп и сразу метнет свой любимый вопрос "А зачем?" :)) объясню в почему так. Есть пожелание, что бы для detail`а действовали все стандартные сервисы для проекта. В том числе и фильтрация. Плюс есть желание использовать для отображения одних и тех же запросов одни и те же dataObject`ы (то что в одном месте detai, в другом может быть master`ом). Мне кажется, что с точки зрения поддержания в дальнейшем это большой плюс (ИМХО, тьма "почти одинаковых" объектов - зло). Да и вообще... очень заинтересовал этот вопрос, т.к. никогда не задумывался как это реализовано (не нужно было), а посмотрел... несколько в оторопь вогнало... Неужели для deteil`а в принципе не подразумевается использование retrieve параметров окромя тех, что связывает его с master`ом?

2 Estets
Estets ДремучийНа всякий случай (а то придет Филипп и сразу метнет свой любимый вопрос "А зачем?" :))
Ну тогда я спрошу "А зачем" нужна фильтрация в списке накладной отличная от самой накладной? Можно использовать dw.Find() или dw.Filter() вариантов использования аргументов SELECT-а я не вижу.

Как вариант созранение в MASTER записи дополнительных полей и использование их для SELECT-а DETAIL записей.
Пример (абстрактный, но думаю наглядный).
Одна форма. На ней мастер и детейл. Мастер - список клиентов. Детейл - список звонков этих клиентов... На экране больше 30-35 строк на двоих Вы не увидите. А звонков легко может быть за сотню в месяц (три звонка в день не фантастика)...

У нас предметная область другая, но мне клялись, что в детейле количество записей может превышать 1К... однозначно нужен фильтр. dw.filter() у нас не используется - смысл тянуть сразу всю базу когда скорее всего нужны проценты (если не доли процентов) от нее. Создавать для детейла отдельный механизм опирающийся на dw.filter()... не уверен, что это хорошее решение - я сторонник концепции "Один проект, одна идеология, один стиль!". dw.find() мне тоже не нравится - если в детейле дофига записей, то скорее всего перемещение к одной не лечит, т.к. скорее всего нужна не одна строка, а и соседние с ней по какой-то логике.
Кроме того, как я уже говорил, детейл в одном месте может быть мастером в другом (реализация "мастером в другом" уже давно существует)... и что, тогда два dataObjecta в паинтере рисовать? А потом этот зоопарк "дублей" поддерживать и сопровождать?

2 Anatoly Moskovsky
Anatoly MoskovskyМодифицируйте pfc_n_cst_dwsrv_linkage.of_RetrieveDetails так, чтобы она добавляла нужные аргументы к массиву аргументов. Сами значения аргументов можно хранить в u_dw и по какому-то интерфейсу отдавать в of_RetrieveDetails и устанавливать при фильтрации.
Думаете так? Сам я думал в противоположном направлении - перекрыть в n_cst_dwsrv_linkage функцию of_RetrieveDetails и из нее дергать уже какую-нибудь дополнительную фукцию в DW (которая уже дернет retrieve). Причина этого - каждый DW все-таки знает сколько, каких и в какой последовательности ему аргументов нужно для retrieve. А вот linkage об этом без понятия (собственно так он и сделан - плевать ему на что и как, тупо кидает 20 параметров и все).
Просто мне кажется так идеологически более правильно. Но я не уверен в правильности такого решения, вот и вылез на форум.

Anatoly MoskovskyПри Вашем подходе придется писать код этой ф-и для каждого DW со своим набором параметров.

А я предлагаю написать универсальную ф-ю, а к параметрам обращаться через dw.Set(any args[])/dw.Get(any args[])
При этом я считаю несущественным то ограничение, что в списке параметров DW всегда должны идти сначала PK, а потом остальные.
:) На самом деле я предполагал написать универсальную функцию в u_dw. А насчет остального... так и есть. :) Собственно я другого решения не видел, но мне казалось, что должен существовать более изящный путь. По своему я всегда успею сделать, а вот если люди знают более разумное решение, то почему бы не спросить? ;) И наталкивать на то решение что я видел я уже не хотел, т.к. не хотелось сбивать людей с мыслей. :)

2 Модератор
Я сделал как Вы посоветовали. :)

2 Estets
EstetsИменно пример "абстрактный", возьмем пример из жизни, список сделок, которых может быть до 4000 в день, и один из параметров фильтрации это автор сделки. Вот как то не приходило в голову рисовать на экране список клиентов и рядом список сделок, ретривить второй список при изменении позиции в первом, а потом еще заморачиваться а куда же прицепить диапазон дат, так как сделок очень много.

Есть список сделок(звонков), есть фильтр по датам, автору, сумме и пр. но это совсем не master-detail.
1. То что Вам не приходит в голову не значит, что это не придет в голову пользователям системы. Их понятие об "удобно" иногда сильно удивляет.
2. В соседней ветке вопрос о фильтрах обсуждался. Итог - фильтровать используя передачу параметров (как я и предполагал). Именно отсюда и возникла эта ветка, т.к. сейчас некое подобие deteil`а уже организовано - открывается новое окно, где отображается требуемый детейл с сервисными возможностями (по сортировке и фильтрации) как у мастера. И это было сделано не на пустом месте, а по настойчивым пожеланиям пользователей (речь о сервисных возможностях). Естественно, что после открытия окна-detail`а прямая связь с master`ом прерывалась. А сейчас возникло пожелание, что бы это все было (в том числе) и на одном окне (причина - большая наглядность + не нарушается связь master-detail). Отсюда и пляски, т.к. сервисные возможности для detail`а потребуют сразу как только пользователю попадет новый вариант. Соответственно и закладываться надо на это сразу, а не потом думать "а может переписать это все?".

Так что эта ветка возникла не на пустом месте. И то что мне нужно, мне действительно нужно (к сожалению).