Почему display/edit методы не поддерживают переход к основной таблице

[S.Kuskov]

Почему для отдельных контролов (не связанных с источником данных), но c заданым свойством ExtendedDataType нет функции перехода к основной таблице. Аналогичный вопрос для display и edit методов?

[MikeR]

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

[S.Kuskov]

А если указать ExtendedDataType на котором будет relation? Что мешает выполнить переход в таком случае?

[TasmanianDevil]

EDT недоступен для указания в контролах display- и edit-методов, что само по себе логично - сам метод в своем определении несет информацию о EDT возвращаемого значения. Если указывать в этих методах в качестве типа возвращаемого значения EDT того поля, по которому идет расчет возвращаемого значения, то ни к чему хорошему не приведет - кастрируется по размеру результат, да и переход вряд ли работать будет, т.к. есть сильное подозрение, что сия функциональность запрограммирована исключительно для связанных с DS контролами. Если предположить, что цепочка анализа возможности активации этого пункта в контекстном меню выглядит как "контрол -> DS/поле -> таблица/поле в AOT -> EDT поля -> таблица ссылки EDT", то видно, что отвязанный от DS контрол или контрол с display/edit-методом обрубается в цепочке на втором шаге и никакого счастия в виде пункта "Перейти к основной таблице" не будет.

P.S. По поводу отвязанного контрола вопрос и негодование разделяю - логически и технически каких-то препятствий не видится для реализации перехода к таблице.

[imir]

В объявлении метода явно стоит тип возвращаемого значения, так что логичного объяснения, кроме как - "бикоз" тут нет.
А есть у кого-нибудь возможность на 2012-й проверить?

[Pustik]

Присоединяюсь с негодованием и непониманием отсутствия такой возможности.

[S.Kuskov]

Цитата:

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

есть сильное подозрение, что сия функциональность запрограммирована исключительно для связанных с DS контролами

Как-то так... Но табличные display методы и display методы уровня источника данных также остались обделены данной функцилнальностью

[kashperuk]

Ведь форма для перехода к основной таблице указывается на таблице, с которой связан EDT.
В АХ 2012 это работает. В смысле, если создать EDT, связать его с таблицей, и на таблице указан FormRef, переход к основной таблице будет.
Для дисплей методов, имхо, это некорректно

[S.Kuskov]

Цитата:

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

Ведь форма для перехода к основной таблице указывается на таблице, с которой связан EDT.
В АХ 2012 это работает. В смысле, если создать EDT, связать его с таблицей, и на таблице указан FormRef, переход к основной таблице будет.

Хорошо, значит уже поправили.

Цитата:

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

Для дисплей методов, имхо, это некорректно

Почему?

[kashperuk]

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

[Krasher]

Может быть потому, что по большому счёту в дисплей методе можно выводить, к примеру, фразу: "Тут был Вася". Никак не привязанную ни к каким полям никаких таблиц? Либо часть из части поля одной таблицы, часть из другой части другого поля другой таблицы... Надеюсь я не очень путано...

[belugin]

Цитата:

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

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

Тогда щачем его относить к типу, у которого есть Relation? А вообщ в 2012 relation из EDT переносятся на таблицы и имхо улучшений в этой части ожидать не стоит.

[S.Kuskov]

Цитата:

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

Потому-что данные, показываемые в этом поле, скорее всего не относятся к той таблице, к которой будет осуществлятся переход.

Цитата:

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

Может быть потому, что по большому счёту в дисплей методе можно выводить, к примеру, фразу: "Тут был Вася". Никак не привязанную ни к каким полям никаких таблиц? Либо часть из части поля одной таблицы, часть из другой части другого поля другой таблицы... Надеюсь я не очень путано...

Но у таких значений, и расширенный тип должен быть соответствующим (без relation). Разве не так?

[Pustik]

У display-методов, как и у edit-методов есть описание какой тип этот метод возвращает, что-то наподобе

display ItemName itemName()
{
     .........
}

Сбегать и посмотреть есть ли такой EDT ItemName и есть ли у него связь на таблицу,технической и логической проблемы не вижу. Если есть - отображать переход к основной таблице, нет значит нет.Не корректности не вижу тоже. Зато удобно пользователям.

[Raven Melancholic]

А куда, в общем случае, должен быть осуществлен переход? В edit или display методе может быть жутко замороченный алгоритм. Как система должна разобраться что там е этом методе происходит?
Пусть EDT на методе будет AmountMST, в методе производится расчет средней стоимости отгрузок клиенту с условием, что клиент оплачивает на 10% быстрее, чем предоставленная ему отсрочка платежа. Куда переходить ?

[trud]

для AmountMST очевидно никуда, для этого типа нет формы.
А например если возвращается клиент переходить в форму клиентов

[Maxim Gorbunov]

Если нужно показать клиента, то можно и таблицу приджойнить, в которой это поле указано. При этом из таблицы унаследуется вся настройка прав доступа. Не стоит забывать о том, что на display-метод настроить доступ не так-то просто

[S.Kuskov]

Цитата:

Сообщение от Raven Melancholic

А куда, в общем случае, должен быть осуществлен переход? В edit или display методе может быть жутко замороченный алгоритм. Как система должна разобраться что там е этом методе происходит?

А она и не должна. Это решит программист, указав у метода нужный ему тип возвращаемого значения. К слову в случае edit-метода именно таким способом происходит назначение на контрол нужной lookup формы.

[Pustik]

Цитата:

Сообщение от Maxim Gorbunov

Если нужно показать клиента, то можно и таблицу приджойнить, в которой это поле указано.

А если нужно отображать клиента в зависимости от каких-либо условий, которые не подходят под логику Inner Join, Exist Join и т.д. Например, есть форма, которая отображает список номенклатур проданных клиентам за период. В ней рядом с номенклатурой я хочу видеть клиента, которому продал эту номенклатуру по самой дорогой цене за этот период.
В основном эти методы для этого и пишутся.

Цитата:

Сообщение от Maxim Gorbunov

При этом из таблицы унаследуется вся настройка прав доступа. Не стоит забывать о том, что на display-метод настроить доступ не так-то просто

С правами в АХ2009 гайки закручены мама не горюй. Мало того, что теперь проверяются лукапы, дак еще и при желании в коде можно закрыть доступ через соответствующее свойство таблицы. Не думаю, что в этом случае это сложнее.

[kashperuk]

Одним словом, feedback taken - я обсужу, создам баг, а как будут новости, расскажу