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

[S.Kuskov]

Цитата:

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

Нет, Вы всё-таки подумайте: как ограничить доступ на display-метод, определённый на форме?

Согласен с тем, что ответственность за отображение/скрытие контролов нужно по максимому перекладывать на ядро системы. В случае display-метода, этого можно добиться, например, научив систему анализировать relation на расширенном типе данных у значения возвращаемого методом

[lev]

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

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

[Pustik]

Цитата:

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

В любом случае, таких сложносочинённых форм по определению не может быть много.

Согласен . Я просто с ходу придумал пример, который показывает, что присоединение таблицы не всегда заменит display-метод.

Цитата:

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

Нет, Вы всё-таки подумайте: как ограничить доступ на display-метод, определённый на форме?

А чего тут думать-то у display-метода есть EDT, который он возвращает.У EDT relation.Определили таблицу.Смотрим свойство FormRef у соответствующей таблицы, если FormRef пустой тогда вот-так Работа с Lookup.Определили форму.Итак нашли и таблицу и форму - все нужные нам объекты. Дальше определяем права у этих объектов в таблице настройки прав стандартным образом. Думаю если найдены объекты с правами не должно быть проблем.

[Maxim Gorbunov]

Цитата:

Сообщение от 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-метод, который на этот объект ссылается. В существующей идеологии настройки прав доступа это две совершенно разные вещи.

[kashperuk]

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

[TasmanianDevil]

Мы пользуем дописанную функцию в классе Global - и для display/edit - методов, и для контролов, передавая в нее расширенный тип и значение

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));

}

[Link]

Все же обычно display\edit методы отображают неключевые данные, чаще расчетные. И привязать их наверняка просто невозможно. Но если нужно добавить переход к форме, то можно так:

Пример перехода к форме наменклатуры по значению из дисплейного метода.

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;
}

[S.Kuskov]

Цитата:

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

Все же обычно display\edit методы отображают неключевые данные, чаще расчетные. И привязать их наверняка просто невозможно.

Уже обсуждалось на первой странице. В случае, когда данные не могут быть привязаны к какой-либо "основной таблице", то и расширенный тип даных для отображения/ввода таких данных логично использовать без relation'а. По поводу таких случаев вопросов нет. Вопрос, поднятый в этой теме, касается других случаев, когда для создания display/edit методов программист осознано выбирает расширенный тип данных связанный relation'ом с определённой "осовной таблицей". В таких случаях можно было бы и реализовать возможность перехода к основной таблице. И совсем не нужно анализировать содержащееся в контроле значение, для определения направления перехода. Направление перехода изначально предопределено relation'ом на ExtendedDataType.