Поррассуждаем? Как лучше работать с парой связанных значений в классах? (например, nullable)

[Владимир Максимов]

Хм.. Вроде как и есть что сказать по теме, но, вроде бы и так уже все сказано. Только систематизировано несколько по другому, из-за чего и "едет крыша". Как мне кажется, критически важным является ответ на первую "хотелку".

Цитата:

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

Какие манипуляции хотелось бы делать с подобными значениями в Аксапте:

• хранить в базе

Возможные варианты:

1. Выделить (интерпретировать) одно из значений как null
   • Выделенное значение отображается как пустое значение в диалоге с пользователем (255 для Base Enum, num2char(160) для String, 0.0001 для AmountCur, 0.1 для CheckBox и т.д и т.п.)
   • Выделенное значение не может быть отображено "как есть" в диалоге с пользователем. Требуется "перевод" (maxDate() для Date, maxInt() для int и т.п.)
2. Добавить еще один признак (поле), показывающий, что "основное" значение надо интерпретировать как null. Одно дополнительное поле может "обслуживать" несколько "основных" полей.
   • Отдельный признак имеет самостоятельное значение и отдельно отображается в диалоге с пользователем. Например, признак "Контролировать кредитный лимит" определяет учитывать ли значения полей "Сумма лимита" и "Дата установки контроля"
   • Отдельный признак является "системным" (служебным) полем и для пользователя недоступен. Например, признак значения NULL для контрольной суммы (Хотя... Впрочем, за не именеем более наглядного примера)

Дальнейшая реализация будет существенным образом зависеть от выбранного способа хранения значения NULL в базе данных. Ну, с первыми 3 вариантами дальнейшая работа понятна. Обычный набор переменных. Некоторые сложности может доставить перекодировка из maxdate() в пустое значение для отображения, но не думаю, что эта такая уж большая проблема.

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

Цитата:

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

• спрашивать значения у пользователя на формах и в программных диалогах

Каким образом будет построен интерфейс с пользователем, чтобы пользователь мог понять, где значение будет интерпретировано как null, а где - как указанное значение? Пусть даже пользователь и "не трогал" этого значения. Или "потрогал", но вернул назад

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


Если же рассматривать вопрос БЕЗ учета этих двух основных "хотелок", например, как передача неких параметров при расчетах, то можно рассмотреть еще парочку вариантов.

• Очень ограниченно можно использовать (prmIsDefault() == 1) как признак того, что параметр передан не был. Т.е. интерпретировать это как передачу null. Правда, для pack/unpack это не пригодно, но ведь интерфейс с пользователем нас не интересует
• В среде Axapta значение NULL физически может быть сохранено в переменной типа ComVariant. В принципе, тот же класс, но чуть проще

    COMVariant comVariant;
    ;
    comVariant = new ComVariant(COMVariantInOut::In_out, ComVariantType::VT_BOOL);
    info(comVariant.toString());
    info(strFmt('%1',comVariant.variantType()));

    comVariant.variantType(ComVariantType::VT_NULL);
    info(comVariant.toString());
    info(strFmt('%1',comVariant.variantType()));