Для решения каких задач могут потребоваться ОДНОВРЕМЕННО и dynalink, и link на одном датасорсе?

[belugin]

Цитата:

Сообщение от mazzy

в этом случае запрос будет выглядеть так:

спецформа
└датасорс: шапки инвойсов (dynalink: строки поставщики)
 └датасорс: строки инвойсов (link: шапки инвойсов)

За счёт чего в в той же самой форме поменяется порядок источников данных для вызова из другого места?

Цитата:

и я плохо выделил слово ОДНОВРЕМЕННО?

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

[mazzy]

Цитата:

Сообщение от belugin

За счёт чего в в той же самой форме поменяется порядок источников данных для вызова из другого места?

по-нормальному, тот же программист-орел, что добавляет dynalink на внутренние датасорсы.

Цитата:

Сообщение от belugin

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

Пля...

Я накидал макетик на ax2012 и ax2009.

получается, что диналинк можно добавить вручную в коде на внутреннюю таблицу. и он даже будет работать. см. приложенный проект и скриншоты с одновременным существованием ветки dynalink и relation.

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

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

ок, согласен, что исходный вопрос нужно уточнить: Для решения каких бизнес-задач могут потребоваться ОДНОВРЕМЕННО и dynalink, и link на одном датасорсе?

[mazzy]

Цитата:

Сообщение от mazzy

Я накидал макетик на ax2012 и ax2009.

Уточнил макетик.

Раньше я лихо использовал innnerJoin между датасорсами спец-формы.
Одумался и сделал вариант с DelayedJoin.

Конечно же в варианте в delayed join нет одновременного dynalink и link.
Конечно же в варианте в delayed join работает совсем не так как ожидает пользователь - фильтрует только внутреннюю таблицу, а шапки оставляет нетронутыми.

В общем, очень спорный прием разработки.
Мне кажется, что на проекте такой способ приведет к большим проблемам, нежели сделать еще одну форму.

[belugin]

Цитата:

Сообщение от mazzy

Раньше я лихо использовал innnerJoin между датасорсами спец-формы.
Одумался и сделал вариант с DelayedJoin.

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

Кстати, интересно, что получится если сделать exists join и на второй датасурс навесить дайналинк. ( Мы хотим например увидеть не в одном гриде а в двух, но чтобы шапки фильтровались но наличию строк с текущей номенклатурой)

Цитата:

В общем, очень спорный прием разработки.
Мне кажется, что на проекте такой способ приведет к большим проблемам, нежели сделать еще одну форму.

Я думаю это зависит от сложности формы. Если там много всего, возможно, проще поддерживать одну сложную форму чем две сложных формы. Причем продублировать форму просто в сравнении с тем, чтобы объединить две формы в одну.

Кстати, не факт что кто-то вообще думал о таких сценариях -просто есть две концептуально ортогональных возможности и их одновременное применение не запретили. Как в paint можно залить холст черным и рисовать по нему черным карандашом.

[mazzy]

Цитата:

Сообщение от mazzy

Для решения каких бизнес-задач могут потребоваться ОДНОВРЕМЕННО и dynalink, и link на одном датасорсе?

Цитата:

Сообщение от belugin

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

пока выявляются только технические задачи, связанные с программированием.
ни разу не видал пользователя, который ставил бы задачу именно так "в одном гриде".

такое вспоминается только в связи со всякими InventDim или безумными фин.аналитиками 2012, когда программисты ради своих технических целей "нормализовали" на разные таблицы, а пользователи постоянно напоминают - "уберите вашу нормализацию, верните в одну строку".

Цитата:

Сообщение от belugin

Я думаю это зависит от сложности формы. Если там много всего, возможно, проще поддерживать одну сложную форму чем две сложных формы. Причем продублировать форму просто в сравнении с тем, чтобы объединить две формы в одну.

надо подумать.

Цитата:

Сообщение от belugin

Кстати, не факт что кто-то вообще думал о таких сценариях -просто есть две концептуально ортогональных возможности и их одновременное применение не запретили.

А вот с этим готов согласиться.
Собственно вопрос то отсюда и сформулировался - есть ли какие-нибудь признаки у хотелок пользователя, которые однозначно указывают что необходим и dynalink, и link.

из этих признаков наверное можно получить понимание что такое dynalink и link. и чем они отличаются. из этого понимания наверное можно получить понимание чем аксапта отличается от других систем. выйти на приемы применения аксапты. и на понимание как решают задачу другие системы.

пока не вижу ничего, кроме технического - dynalink это delayed link.
но такое проще было бы реализовать параметрами линка, а не отдельным механизмом.
возможно еще что-то есть, чего я в упор не понимаю.

поэтому вопрос:
Для решения каких бизнес-задач могут потребоваться ОДНОВРЕМЕННО и dynalink (=delayed link), и обычный link на одном датасорсе?

[belugin]

Цитата:

Сообщение от mazzy

ни разу не видал пользователя, который ставил бы задачу именно так "в одном гриде".

Я какие-то такие формы делал. Наверное пользователи говорят что-то типа "мы хотим видеть тут вот это и вот это и мы не хотим каждый раз тыкать чтобы увидеть поля связанные с другой строкой, а ещё мы хотим Эксель и фильтр по тому, что видим".