AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 01.11.2011, 13:32   #21  
Maxim Gorbunov is offline
Maxim Gorbunov
Administrator
Соотечественники
Лучший по профессии 2009
 
2,483 / 645 (26) +++++++
Регистрация: 27.11.2001
Адрес: Dubai, UAE
Цитата:
Сообщение от Pustik Посмотреть сообщение
А если нужно отображать клиента в зависимости от каких-либо условий, которые не подходят под логику Inner Join, Exist Join и т.д. Например, есть форма, которая отображает список номенклатур проданных клиентам за период. В ней рядом с номенклатурой я хочу видеть клиента, которому продал эту номенклатуру по самой дорогой цене за этот период.
Решений может быть масса. Соберите данные во временную таблицу, например. Или добавьте свой собственный метод перехода к основной таблице. В любом случае, таких сложносочинённых форм по определению не может быть много. Я бы оценил в процентов 5 от общего количества (если у Вас их больше, имеет смысл задать себе вопрос, почему я так мало пользуюсь отчётами ). Ради такого количества править логику работы прав доступа, dynamic links, и т.д.... в общем, знаете, в этом конкретном случае я на стороне разработчиков из MS

Цитата:
Сообщение от Pustik Посмотреть сообщение
С правами в АХ2009 гайки закручены мама не горюй. Мало того, что теперь проверяются лукапы, дак еще и при желании в коде можно закрыть доступ через соответствующее свойство таблицы. Не думаю, что в этом случае это сложнее.
Нет, Вы всё-таки подумайте: как ограничить доступ на display-метод, определённый на форме?
__________________
Not registered yet? Register here!
Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me
Старый 01.11.2011, 14:10   #22  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,438 / 1775 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от Maxim Gorbunov Посмотреть сообщение
Нет, Вы всё-таки подумайте: как ограничить доступ на display-метод, определённый на форме?
Согласен с тем, что ответственность за отображение/скрытие контролов нужно по максимому перекладывать на ядро системы. В случае display-метода, этого можно добиться, например, научив систему анализировать relation на расширенном типе данных у значения возвращаемого методом
Старый 01.11.2011, 16:14   #23  
lev is offline
lev
Ищущий знания...
Аватар для lev
Oracle
MCBMSS
Axapta Retail User
 
1,723 / 491 (20) +++++++
Регистрация: 18.01.2005
Адрес: Москва
Читал, читал ветку, и решил сюда же запостить пожелание о том, что бы была возможность перейти к основной таблице из поля диалога, который был создан с помощью класса Dialog. Это конечно мелочь, но иногда очень этого не хватает.

Ну конечно проверять на основе какого EDT (и вообще на его ли основе) создано поле в диалоге, и если у этого EDT есть Relation (ну или заполнено свойство HelpForm), то дать возможность перейти к основной таблице.
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с)
С Уважением,
Елизаров Артем
Старый 01.11.2011, 16:37   #24  
Pustik is offline
Pustik
Участник
 
807 / 372 (14) ++++++
Регистрация: 04.06.2004
Цитата:
Сообщение от Maxim Gorbunov Посмотреть сообщение
В любом случае, таких сложносочинённых форм по определению не может быть много.
Согласен . Я просто с ходу придумал пример, который показывает, что присоединение таблицы не всегда заменит display-метод.
Цитата:
Сообщение от Maxim Gorbunov Посмотреть сообщение
Нет, Вы всё-таки подумайте: как ограничить доступ на display-метод, определённый на форме?
А чего тут думать-то у display-метода есть EDT, который он возвращает.У EDT relation.Определили таблицу.Смотрим свойство FormRef у соответствующей таблицы, если FormRef пустой тогда вот-так Работа с Lookup.Определили форму.Итак нашли и таблицу и форму - все нужные нам объекты. Дальше определяем права у этих объектов в таблице настройки прав стандартным образом. Думаю если найдены объекты с правами не должно быть проблем.
__________________
-Ты в гномиков веришь?
-Нет.
-А они в тебя верят, смотри, не подведи их.
Старый 01.11.2011, 17:25   #25  
Maxim Gorbunov is offline
Maxim Gorbunov
Administrator
Соотечественники
Лучший по профессии 2009
 
2,483 / 645 (26) +++++++
Регистрация: 27.11.2001
Адрес: Dubai, UAE
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
Согласен с тем, что ответственность за отображение/скрытие контролов нужно по максимому перекладывать на ядро системы. В случае display-метода, этого можно добиться, например, научив систему анализировать relation на расширенном типе данных у значения возвращаемого методом
А теперь давайте вспомним, что вообще-то в системе права на primary key и права на foreign key - две разные вещи. То есть, например, если дать пользователю смотреть список заказов, но скрыть таблицу клиентов, поле Клиент в заказе можно оставить доступным. Если делать, как предлагаете Вы, то придётся либо отказаться от такого подхода, либо написать большой документ для администраторов, в котором перечислить, в каких случаях работает так, а в каких - иначе. Кстати, подумайте ещё о том, что тот, кто настраивает права, далеко не всегда (на моей практике так почти никогда) имеет представление о программировании в системе, и для него разница между dislpay-методом и полем в таблице весьма условна.
Цитата:
Сообщение от lev Посмотреть сообщение
Читал, читал ветку, и решил сюда же запостить пожелание о том, что бы была возможность перейти к основной таблице из поля диалога, который был создан с помощью класса Dialog. Это конечно мелочь, но иногда очень этого не хватает.

Ну конечно проверять на основе какого EDT (и вообще на его ли основе) создано поле в диалоге, и если у этого EDT есть Relation (ну или заполнено свойство HelpForm), то дать возможность перейти к основной таблице.
Помню, как меня однажды консультант ругал, когда я добавил такую возможность в своём диалоге. Пришлось убирать

Цитата:
Сообщение от Pustik Посмотреть сообщение
Согласен . Я просто с ходу придумал пример, который показывает, что присоединение таблицы не всегда заменит display-метод.
Я Вам также сходу предложил, как это можно решить, не ломая ядра По-прежнему не вижу реальной пользы в такой фиче.

Цитата:
Сообщение от Pustik Посмотреть сообщение
А чего тут думать-то у display-метода есть EDT, который он возвращает.У EDT relation.Определили таблицу.Смотрим свойство FormRef у соответствующей таблицы, если FormRef пустой тогда вот-так Работа с Lookup.Определили форму.Итак нашли и таблицу и форму - все нужные нам объекты. Дальше определяем права у этих объектов в таблице настройки прав стандартным образом. Думаю если найдены объекты с правами не должно быть проблем.
Ага. Только заметьте, что определяете таким образом Вы права на объект, а не на display-метод, который на этот объект ссылается. В существующей идеологии настройки прав доступа это две совершенно разные вещи.
__________________
Not registered yet? Register here!
Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me
Старый 01.11.2011, 17:39   #26  
lev is offline
lev
Ищущий знания...
Аватар для lev
Oracle
MCBMSS
Axapta Retail User
 
1,723 / 491 (20) +++++++
Регистрация: 18.01.2005
Адрес: Москва
Цитата:
Сообщение от Maxim Gorbunov Посмотреть сообщение
Помню, как меня однажды консультант ругал, когда я добавил такую возможность в своём диалоге. Пришлось убирать
А какое обоснование ругани было (если не секрет) ?
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с)
С Уважением,
Елизаров Артем
Старый 01.11.2011, 18:06   #27  
Pustik is offline
Pustik
Участник
 
807 / 372 (14) ++++++
Регистрация: 04.06.2004
Цитата:
Сообщение от Maxim Gorbunov Посмотреть сообщение
Помню, как меня однажды консультант ругал, когда я добавил такую возможность в своём диалоге. Пришлось убирать
За что Ваш консультант так не любит пользователей? Ведь удобно же
Цитата:
Сообщение от Maxim Gorbunov Посмотреть сообщение
Я Вам также сходу предложил, как это можно решить, не ломая ядра
А так ломается ядро пользователя..Здесь надо через "Перейти к основной таблице", а там по кнопочке справа в пункте меню.
Цитата:
Сообщение от Maxim Gorbunov Посмотреть сообщение
Ага. Только заметьте, что определяете таким образом Вы права на объект, а не на display-метод, который на этот объект ссылается. В существующей идеологии настройки прав доступа это две совершенно разные вещи
Дак ведь здесь речь-то идет о возможности "Перейти к основной таблице". Т.е. права на этот display-метод настроены уже изначально. И если пользователь видит этот метод значит права настроены так, что он должен видить этот метод. Остается проверить права как-раз на объекты, которые он может открыть через "Перейти к основной таблице". Или я что-то не понимаю. Поправьте если я не прав.
__________________
-Ты в гномиков веришь?
-Нет.
-А они в тебя верят, смотри, не подведи их.
Старый 01.11.2011, 18:11   #28  
Maxim Gorbunov is offline
Maxim Gorbunov
Administrator
Соотечественники
Лучший по профессии 2009
 
2,483 / 645 (26) +++++++
Регистрация: 27.11.2001
Адрес: Dubai, UAE
Цитата:
Сообщение от lev Посмотреть сообщение
А какое обоснование ругани было (если не секрет) ?
Ну, уж прямо ругани-то не было Если честно, подробностей я уже не помню. Задача была поставлена так: сделать, чтобы работало, как все остальные стандартные диалоги. Возможно, идея в том, что диалог предполагает некоторую модальность, и не хотелось давать пользователям лишний повод про неё забыть.
__________________
Not registered yet? Register here!
Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me
Старый 01.11.2011, 18:19   #29  
Maxim Gorbunov is offline
Maxim Gorbunov
Administrator
Соотечественники
Лучший по профессии 2009
 
2,483 / 645 (26) +++++++
Регистрация: 27.11.2001
Адрес: Dubai, UAE
Цитата:
Сообщение от Pustik Посмотреть сообщение
А так ломается ядро пользователя..Здесь надо через "Перейти к основной таблице", а там по кнопочке справа в пункте меню.
Если очень надо (в чём у меня по-прежнему большие сомнения), можно и без кнопочки. Перекрывайте метод jumpRef() на контроле и программируйте, сколько хотите Я же не говорю, что так делать вообще никогда нельзя. Я лишь говорю, что это настолько специфическая задача, что решать её с помощью ядра - это overkill. Дайте разработчикам MS шанс поработать над более существенными проблемами

Цитата:
Сообщение от Pustik Посмотреть сообщение
Дак ведь здесь речь-то идет о возможности "Перейти к основной таблице". Т.е. права на этот display-метод настроены уже изначально. И если пользователь видит этот метод значит права настроены так, что он должен видить этот метод. Остается проверить права как-раз на объекты, которые он может открыть через "Перейти к основной таблице". Или я что-то не понимаю. Поправьте если я не прав.
Не, мы про разные вещи говорим. Я говорю именно про доступ на тот самый контрол, который отображает значение display-метода. Как его спрятать отдельно от формы/таблицы, к которой он привязан?
__________________
Not registered yet? Register here!
Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me
Старый 01.11.2011, 18:37   #30  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,438 / 1775 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от Maxim Gorbunov Посмотреть сообщение
А теперь давайте вспомним, что вообще-то в системе права на primary key и права на foreign key - две разные вещи. То есть, например, если дать пользователю смотреть список заказов, но скрыть таблицу клиентов, поле Клиент в заказе можно оставить доступным.
Совершенно верно, но вводить код клиента прийдётся вручную без лукап-формы
Цитата:
Сообщение от Maxim Gorbunov Посмотреть сообщение
Если делать, как предлагаете Вы, то придётся либо отказаться от такого подхода, либо написать большой документ для администраторов, в котором перечислить, в каких случаях работает так, а в каких - иначе.
Согласен про анализ Relation на ExtendedDataType я возможно поторопился. Но анализ самих ExtendedDataType в теории может предоставить такой инструмент. Как вы считаете, ExtendedDataType гипотетически может выступать объектом-еденицей настройки прав доступа? На память не помню а проверить возможности сейчас нет. Есть ли у объекта ExtendedDataType свойство SecurityKey?
Старый 01.11.2011, 18:49   #31  
Maxim Gorbunov is offline
Maxim Gorbunov
Administrator
Соотечественники
Лучший по профессии 2009
 
2,483 / 645 (26) +++++++
Регистрация: 27.11.2001
Адрес: Dubai, UAE
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
Совершенно верно, но вводить код клиента прийдётся вручную без лукап-формы
А никто и не говорит, что этот пользователь создаёт новые заказы Может это кладовщик.
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
Как вы считаете, ExtendedDataType гипотетически может выступать объектом-еденицей настройки прав доступа?
Боюсь, что это только усложнит уже имеющуюся систему. Да и не очень понятно, как такую задачу решить в принципе. Например, EDT могут наследоваться. Как это будет поддерживаться системой настройки прав?
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
На память не помню а проверить возможности сейчас нет. Есть ли у объекта ExtendedDataType свойство SecurityKey?
Нет. Есть только ConfigurationKey.
__________________
Not registered yet? Register here!
Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me
Старый 02.11.2011, 08:49   #32  
lev is offline
lev
Ищущий знания...
Аватар для lev
Oracle
MCBMSS
Axapta Retail User
 
1,723 / 491 (20) +++++++
Регистрация: 18.01.2005
Адрес: Москва
Цитата:
Сообщение от Maxim Gorbunov Посмотреть сообщение
Ну, уж прямо ругани-то не было Если честно, подробностей я уже не помню. Задача была поставлена так: сделать, чтобы работало, как все остальные стандартные диалоги. Возможно, идея в том, что диалог предполагает некоторую модальность, и не хотелось давать пользователям лишний повод про неё забыть.
Так я и говорю про то, что бы добавили эту возможность в базовый функционал системы, и что бы это было бы для всей системы нормой

По поводу "модальности" диалогового окна, вопрос спорный...
В системе диалог открывается не как модальная форма, и это хорошо! Ведь иногда, что бы заполнить поля диалога, нужно сходить в некоторые справочники, и уточнить какое же значение нужно выбрать. Если диалог будет модальным, то его надо будет в начале закрыть, потом уже ходить по справочникам, а вся информация которая уже была введена в диалоге потеряется и её надо будет вводить заново, что не есть хорошо (ведь на диалоге может быть с десяток полей, и вот заполнив 9 (15) полей ты понимаешь, что сейчас тебе надо закрыть окно, а потом заново 9-ть (15-ть) полей заполнить... уверен пользователь по этому поводу немного расстроился бы ).

Так вот, я как раз для таких случаев (когда надо посмотреть уточняющие параметры в справочниках для указания какого то значения в диалоге) и предлагаю добавить возможность перехода к форме основной таблицы прям из диалога, мне кажется это очень удобным (на личном опыте, очень часто об этом вспоминаю ).
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с)
С Уважением,
Елизаров Артем
Старый 26.04.2012, 08:09   #33  
TasmanianDevil is offline
TasmanianDevil
Мрачный тип
Аватар для TasmanianDevil
Злыдни
 
886 / 389 (14) ++++++
Регистрация: 24.01.2005
Адрес: Томск
Мы пользуем дописанную функцию в классе Global - и для display/edit - методов, и для контролов, передавая в нее расширенный тип и значение
X++:
static void makeJump(int _typeId, Anytype _id)
{
    SysDictType     dictType;
    SysDictRelation typeRelation;
    TableId         relationTable;
    FieldId         relationField;
    SysDictTable    dictTable;
    Common          record;

    str             formRef;
    FormRun         fr;
    Args            args;

    ;

    dictType = new SysDictType(typeid2extendedTypeId(_typeId));

    if(dictType)
    {
        typeRelation = dictType.relationObject();

        relationTable = typeRelation.table();
        relationField = typeRelation.lineExternTableValue(1);

        if(relationTable != 0)
        {
            dictTable = new SysDictTable(relationTable);
            if(dictTable)
            {
                formRef = dictTable.formRef();
                if(formRef)
                {
                    record = dictTable.makeRecord();
                    select record where record.(relationField) == _id;

                    if(record)
                    {
                        args = new Args(formRef);
                        args.record(record);

                        fr = new FormRun(args);
                        fr.init();
                        fr.run();
                        fr.wait();
                    }
                    else
                        throw error(strfmt('Для таблицы %1 не найдено значение поля %2 равное "%3"', tableid2name(relationTable), fieldid2name(relationTable, relationField), _id));
                }
                else
                    throw error(strfmt('Таблица %1 не имеет определенной в АОТ формы отображения', tableid2name(relationTable)));
            }
            else
                throw error(strfmt('У расширенного типа %1 в АОТ указана в качестве связанной несуществующая таблица с кодом %2', dictType.name(), relationTable));
        }
        else
            throw error(strfmt('Расширенный тип %1 не имеет в АОТ указания на связанныую с ним таблицу', dictType.name()));
    }
    else
        throw error(strfmt('В системе отсуствует расширенный тип данных с кодом %1', _typeId));

}
__________________
Мы летаем, кружимся, нагоняем ужасы ...
За это сообщение автора поблагодарили: macklakov (5), Logger (5), lev (4), Krasher (1), S.Kuskov (5).
Старый 26.04.2012, 19:04   #34  
Link is offline
Link
Британский учённый
Аватар для Link
Соотечественники
 
568 / 523 (19) +++++++
Регистрация: 25.11.2005
Адрес: UK
Записей в блоге: 9
Все же обычно display\edit методы отображают неключевые данные, чаще расчетные. И привязать их наверняка просто невозможно. Но если нужно добавить переход к форме, то можно так:

Пример перехода к форме наменклатуры по значению из дисплейного метода.
X++:
public int showContextMenu(int _menuHandle) 
{ 
    Args                                args;
    FormRun                             formRun;
    
    int                                 goto;
    int                                 selection;
    
    PopupMenu                           popupMenu = PopupMenu::create(_menuHandle, this.hWnd());
; 
    popupMenu.insertBreak();

    goto        = popupMenu.insertItem("Go to form");
    selection   = popupMenu.draw(); 

    switch (selection) 
    { 
        case goto:
            args = new Args();
            args.name(formstr(InventTable));
            args.record(InventTable::find(this.valueStr()));

            formRun = classFactory.formRunClass(args);

            formRun.init();
            formRun.run();
            return 0;
        default:
            return selection;
    } 

    return selection;
}
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще.
За это сообщение автора поблагодарили: S.Kuskov (5).
Старый 26.04.2012, 19:24   #35  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,438 / 1775 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от Link Посмотреть сообщение
Все же обычно display\edit методы отображают неключевые данные, чаще расчетные. И привязать их наверняка просто невозможно.
Уже обсуждалось на первой странице. В случае, когда данные не могут быть привязаны к какой-либо "основной таблице", то и расширенный тип даных для отображения/ввода таких данных логично использовать без relation'а. По поводу таких случаев вопросов нет. Вопрос, поднятый в этой теме, касается других случаев, когда для создания display/edit методов программист осознано выбирает расширенный тип данных связанный relation'ом с определённой "осовной таблицей". В таких случаях можно было бы и реализовать возможность перехода к основной таблице. И совсем не нужно анализировать содержащееся в контроле значение, для определения направления перехода. Направление перехода изначально предопределено relation'ом на ExtendedDataType.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Не работает переход к основной таблице. samolalex DAX: Программирование 3 14.02.2011 16:13
Накладной расход, переход к основной таблице ZVV DAX: Программирование 0 03.03.2010 16:55
Переход на правильную запись при Переходе к основной таблице. - 2 Anais DAX: Программирование 2 01.11.2004 17:14
Переход на правильную запись при Переходе к основной таблице. Anais DAX: Программирование 11 29.06.2004 19:16
edit и display методы Maxim Gorbunov DAX: База знаний и проекты 4 15.01.2002 12:58

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 03:21.