Вопросы про RunBase

[Logger]

Т.е. идея в том что вы сперва все параметры распаковали, а потом уже поверх них записали все параметры, какие надо. Сохранения сразу после вызова при таком подходе тоже нет. (Хотя не вижу в нем ничего плохого. Кому оно может помешать ?)

[leva]

Ну и дальше что? Вызываем prompt() который опять перетирает все параметры.

[Logger]

Цитата:

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

Ну и дальше что? Вызываем prompt() который опять перетирает все параметры.

Не должен перетирать, потому что в конструкторе уже вызван getLast()
Он при вызове getLast() взводит некий флажок. Так что при вызове Prompt() повторного вызова getLast() и, соответственно, перезатирания не происходит.

[leva]

Цитата:

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

Он при вызове getLast() взводит некий флажок.

Действительно, и как я не заметил. И почему-то такое, лежащее на поверхности решение, тогда никто не предложил.

Но есть правда один момент, бывает что в unpack создается queryRun, который в свою очередь может зависеть от этого параметра. Тут конечно можно вызвать перестроение запроса после всех parm-ов, но хотелось бы не выносить заботу о таких вещах из класса.

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

[leva]

Нашёл как обойти подводный камень с неверным поведением unpack в других случаях - нужно добавить к this.inGetSaveLast() && inPrompt

Может показаться, что я тут фигней занимаюсь, но хочется написать универсальную, красивую и максимально корректную рыбу, чтобы голову больше этим не забивать.

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

Ну, если решение через Construct - не нравится, то можно пойти "другим путем"

Если сделать допущение, что имя параметра вовсе не обязано совпадать с именем сохраняемой в pack/unpack переменной, то все решается значительно проще.

Через parmXXX() записываем переменную parmXXX, а в методе RunBase.dialog() при создании объектов формы диалога пишем примерно следующее

dialogField = dialog.addFieldValue(typeid(MyType), parmXXX ? parmXXX : unpackYYY);

Собственно, на этом и все модификации заканчиваются.

Если передан параметр (parmXXX), то он инициализирует значение объекта на форме диалога и он же будет сохранен, если пользователь его не изменит. Если же параметр не передан, то инициализировать значение объекта на форме диалога будет распакованное значение переменной.

С Query - чуть сложнее, но тоже не особо. Ведь в любом случае должен быть метод по его созданию. Вот в этом методе и анализировать значение параметра.

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

[leva]

Цитата:

Сообщение от Владимир Максимов

Если передан параметр (parmXXX), то он инициализирует значение объекта на форме диалога и он же будет сохранен, если пользователь его не изменит.

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

Цитата:

Сообщение от Владимир Максимов

С Query - чуть сложнее, но тоже не особо. Ведь в любом случае должен быть метод по его созданию. Вот в этом методе и анализировать значение параметра.

В том то и дело, что такой метод есть. Только не забываем, что этот query как правило выводится в диалоге и может быть там изменён. А значит, нужно этот метод вызвать после того как новые parm-параметры заданы, но перед тем как они будут упакованы и отправлены клиентскому объекту (мне пришёл в голову только вариант переопределить prompt и перез super() вызвать.) Либо вызывать при каждом unpack, что добавляет два лишних перестроения этого запроса (даже больше, если это будет пакетным заданием). В моем варианте это делается один раз.

Вот мой вариант с Query. Здесь initQuery тот самый метод, что строит запрос (на основе переданного в качестве параметра).

public boolean unpack(container packedClass)
{
    Version     version = runbase::getVersion(packedClass);
    container   packedQuery;
    Query       query;
    container   params = [#ParamsList];

    switch (version)
    {
        case #CurrentVersion:
            [version, #CurrentList, packedQuery] = packedClass;
            if (packedQuery && SysQuery::isPackedOk(packedQuery))
                query = new Query(packedQuery);
            if (! query)
                throw error("Ошибка");

            if (inPrompt && inGetSaveLast)
            {
                [#ParamsList] = params;
                queryRun = new QueryRun(this.initQuery(query));
            }
            else
                queryRun = new QueryRun(query);

            break;

        default:
            return false;
    }

    return true;
}

[S.Kuskov]

Цитата:

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

1. Есть некий серверный обработчик, который вызывается из основного меню и из формы

Мне кажеться логичным в принципе разделить и не смешивать эти два случая, а точнее не смешивать сами сохраняемые значения. Пусть при запуске через форму будет вестись своя история последних значений, а при запуске из главного меню - своя. Для этого достаточно переопределить один из методов интерфейса SysSaveable (например: lastValueType), в котором возвращать параметр передавыемый через менюайтем и не париться по поводу ручного разруливания сохранённых значений.

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

leva

Описанная задача не то, чтобы совсем уж невозможная, но достаточно экзотическая. sukhanchik уже пытался намекнуть на это. Да и S.Kuskov говорит о том же. Ну, не может один и тот же класс и принимать значение из-вне и доставать это же самое значение из кеша. Не в смысле того, что физически не может, а в том смысле, что подобная задача свидетельствует о том, что у Вас большие проблемы в организации структуры классов.

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

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