Забавный глюк с Enum

[Poleax]

Из \Data Dictionary\Tables\InventTable\ беру поле ItemType в свою табличку.
В таблице у поля ItemType выставляю свойство Mandatory = Yes.

На форме вывожу поле на Grid. В выпадающем списке исчезает значение "Номенклатура"


У поля ItemType выставляю Mandatory = No.

Перехожу на форму, открываю lookup, и вижу


При чем данный глюк не появляется, если Mandatory = Yes выставить у поля в Data Source формы.

DAX 2009 SP1 GLS EE Rollup 5

[AndyD]

Для обязательного поля нельзя будет устанавливать значение, равное 0 - вот лукап и не показывать "Номенклатуру" (Value=0)

PS На трешке ровно такое же поведение

[oip]

Поле с типом 'Энум' не должно быть мандатори. Но если программист все-таки сделал его мандатори, то умная Аксапта убирает из энума нулевое значение. Так всегда было.

[George Nordic]

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

С Уважением,
Георгий

[dmitro]

Либо делать enum со значением "пусто" и id равным 0. Тогда можно указывать mandatory

[oip]

Цитата:

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

Тогда можно указывать mandatory

Плохой совет. Не должно поле Enum быть мандатори.

Цитата:

Best Practices for Table Field Properties

Mandatory - You should set this to No for enum fields.

[Geo]

Цитата:

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

Плохой совет. Не должно поле Enum быть мандатори.

Помимо ссылки на БестПрактис, есть какие-нибудь логические соображения, почему этого не стоит делать (с описанным приемом: нулевым значением держать "Пустое")?

[oip]

Потому, что это не соответствует тому, что принято в Аксапте. Потому, что программист, который будет потом с этим работать, не будет этого ожидать. Потому, что в разных случаях в лукапе этот энум будет показывать разный список значений. Зачем вообще Бест Практис нужен? Энум - он на то и энум. У него всегда какое-то значение есть.

[sukhanchik]

Цитата:

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

Потому, что это не соответствует тому, что принято в Аксапте. Потому, что программист, который будет потом с этим работать, не будет этого ожидать.

Этот аргумент уже более чем достаточен, чтобы так не делать. Другой программист не будет знать про прием с пустым значением и наступит на "сюрприз" (допустим захочет переименовать пустое значение и будет долго думать - почему при выборе значения в таблице - этого значения нет).

А вообще в свое время участник db очень грамотно сказал в отношении отклонения от Best Practice:

Цитата:

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

Да никто и не спорит. Но на заборе было написано "Острожно! злая собака" - было. Значит за порванные штаны и порванное то что под штанами претензии предъявлять почти бесполезно

[CDR]

Цитата:

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

Помимо ссылки на БестПрактис, есть какие-нибудь логические соображения, почему этого не стоит делать (с описанным приемом: нулевым значением держать "Пустое")?

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

Теряется фильтр из-за того, что не задан label

[Poleax]

Цитата:

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

Поле с типом 'Энум' не должно быть мандатори. Но если программист все-таки сделал его мандатори, то умная Аксапта убирает из энума нулевое значение. Так всегда было.

Тогда почему "умная" аксапты не убирает 0 значение из lookup, если Mandatory = Yes выставить у поля в Data Source формы?

Делали бы тогда однотипно.

[oip]

Не знаю. Да и не хочу знать, честно говоря. Так ли это важно? Как выше уже сказали, если в Best Practices написано "Острожно! злая собака" значит за порванные штаны и порванное то что под штанами претензии предъявлять почти бесполезно.

[titov]

Цитата:

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

Тогда почему "умная" аксапты не убирает 0 значение из lookup, если Mandatory = Yes выставить у поля в Data Source формы?

Делали бы тогда однотипно.

Все объясняется.
В бизнес-логике много ситуаций, когда необходимо при изменениях, например статуса записи, ОБЯЗАТЕЛЬНО указать значение перечисления (подразумевается есть 0 = пусто = неопределено - до смены статуса записи). Так вот по бест-практик и надо подсветить такое поле красным, мало того не контрол, а объект-поле на дата-соурсе, чтобы не сломать механизм, когда пользователь может через настройки пользователя добавить свой контрол в произвольную группу контролов на форме. Вот второй дубль контрол также станет обязательным. В данном примере форма - форма смены статуса записи и указания нужного значения перечисления. При этом до этой формы - смены статуса значение перечисления может быть неопределено, а записи создаются на другой форме, где значение поля НЕОБЯЗАТЕЛЬНО и это требование бизнес-логики.

Насчет возможности сделать поле енум на таблице обязательным - да бест практик РЕКОМЕНДУЕТ не делать чего-то, а как бы Аксапта разрешает. Пример - две таблицы - первая имеет запись с полем енум - необязательно, вторая - история этой записи - вот там енум ставим обязательно, да отходим от бест-практик - в истории не может быть неопределенного статуса записи - тут приоритет другого требования бест-практик - в таблице не должно быть записи с некорректным значением, и закрывается такая ситуация именно на таблице. Смысл такой - если вторую таблицу открыть даже в обозревателе (что делается консультантами часто), то не смогут создать, изменить там запись некорректно. Здесь как раз ситуация что программист ожидает такого поведения, потому-что во второй таблице она логична.

[titov]

Цитата:

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

Тогда почему "умная" аксапты не убирает 0 значение из lookup, если Mandatory = Yes выставить у поля в Data Source формы?

Делали бы тогда однотипно.

А на вопрос то не ответил... Да есть такое. Мало того еще и не подсвечивает красным контрол.

[oip]

Цитата:

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

При этом до этой формы - смены статуса значение перечисления может быть неопределено, а записи создаются на другой форме, где значение поля НЕОБЯЗАТЕЛЬНО и это требование бизнес-логики.
...
вот там енум ставим обязательно, да отходим от бест-практик - в истории не может быть неопределенного статуса записи - тут приоритет другого требования бест-практик - в таблице не должно быть записи с некорректным значением, и закрывается такая ситуация именно на таблице.

Не согласен. А сделать проверку где-нибудь, да хоть в validateWrite() не подойдет? Приведите, пожалуйста, пример обязательного поля с типом Энум в стандартной Аксапте. Согласитесь, что маловероятно, чтобы было так, что в очень большом стандартном приложении такого примера не было, а в неком проекте с количеством доработок явно на несколько порядков меньше уже имеющегося кода без этого не обойтись.

Upd. У BaseEnum любое значение - уже "непустое". Просто потому, что это "перечисление". Даже если вы некое из значений почему-то рассматриваете "пустым". И если по бизнес-логике в какой-то ситуации какое-то из значений не должно иметь место быть, то проверка на это должна быть прозрачно видна из кода, а не переложена в неожиданное место, на свойство поля. Свойство "мандатори" проверяет заполненность поля, а в вашем случае поле будет заполнено.

Аналогично, например, нехорошо для поля с типом Энум (за исключением, возможно, типа NoYes), писать 'if (table.enumField)' вместо 'if (table.enumField != BaseEnum::None).

[titov]

джоб нашел 100 объектов для ах2009

static void EnumTypeMandatory(Args _args)
{
    Dictionary      dictionary = new Dictionary();
    DictTable       dictTable;
    DictField       dictField;
    int             countFiledsTotal;
    tableId         tableId;
    fieldId         fieldId;
    ;
    setprefix('Сканирование АОТ. Таблицы, имеющие поле enum mandatory');
    for (tableId = dictionary.tableNext(0);tableId;tableId = dictionary.tableNext(tableId))
    {
        dictTable = new DictTable(tableId);
        if ( (! dictTable.isMap()) && (! dictTable.isTmp()) && (! dictTable.isView()))
        {
            setPrefix(dictTable.name() + '-' + dictTable.label());
            for (fieldId = dictTable.fieldNext(0);fieldId;fieldId = dictTable.fieldNext(fieldId))
            {
                dictField = dictTable.fieldObject(fieldId);
                

                if(         dictField.type()        == types::Enum
                        &&  dictField.mandatory()   == true
                  )
                {
                    info(dictField.name() + '-' + dictField.label());
                    countFiledsTotal++;
                }
            }
        }
    }
 
    info(strFmt("Total found %1 objects",countFiledsTotal));
}

[kornix]

Столкнулся с таким же поведением enum'а в существующей нестандартной таблице. Не догадался обратить внимание на свойство mandatory табличного поля, почему-то казалось что что-то хитрое с enum'ом или EDT. Респект за тему