Всегда ли надо прописывать список переменных в pack?

[DSPIC]

Цитата:

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

Всегда ли надо прописывать список переменных в pack?

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

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

Цитата:

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

В чем именно проблема, я уже потерялся - сформулируйте еще разок.

1. Переменную, которую заполняет пользователь в диалоге, сохранять в кеше не надо. Новый вызов диалога - заново заполняем

2. Класс имеет свойство RunOn = Server. При "стандартной" реализации это свойство требует наличия pack(), чтобы организовать передачу значений из формы диалога, открытой на клиенте, в копию обслуживающего эту форму класс, созданную на сервере

Т.е. имеем "конфликт интересов"

С одной стороны pack() не нужен, поскольку не нужна запись в кеш. Но с другой стороны pack() нужен, чтобы обеспечить транспорт между копиями классов на клиенте и на сервере

Соответственно, два пути решения

1. Создаем pack(), но организуем затирание значения полученного из кеша
2. Отказываемся от создания дубликатов класса обслуживания формы на сервере. Т.е. транспорт между клиентом и сервером становится не нужным, как следствие, не нужен и заполненный pack()

[DSPIC]

Цитата:

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

1. Создаем pack(), но организуем затирание значения полученного из кеша

И что смущает в этом подходе?

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

Цитата:

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

И что смущает в этом подходе?

Затирание. Зачем создавать то, что ты использовать не собираешься? Чтобы было?

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

[DSPIC]

Цитата:

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

Затирание. Зачем создавать то, что ты использовать не собираешься? Чтобы было?

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

Цитата:

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

- в методе main, принудительно вызываем getLast(), после чего обнуляем переменную.

А что именно смущает? Так сделано по всей системе, сплошь и рядом.

[S.Kuskov]

Цитата:

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

1. Переменную, которую заполняет пользователь в диалоге, сохранять в кеше не надо. Новый вызов диалога - заново заполняем

Мне кажется вот этот момент нужно подробнее разобрать. Если это чисто интерфейса задача, сделать так чтобы значение по умолчанию контрола на диалоге не бралось из кеша, а оставалось пустым/или ещё каким-то, то и не нужно менять принципы работы с кешем, а нужно менять принципы работы с контролом. А именно, просто при создании не инициализировать у контрола значение по умолчанию переменой из кеша, а инициализировать просто пустым значением/или каким там нужно.

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

[gl00mie]

Цитата:

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

Есть класс - наследник от RunBase со свойством RunOn = Server. Пользователь должен ввести текстовое значение, которое далее будет использовано для обработки. Кешировать это значение не надо. При каждом новом вызове класса текст надо вводить заново. Пакетная обработка не предполагается ни сейчас, ни в будущем. Работоспособность такого класса можно обеспечить двумя способами:

1. Поставить "заглушку" в pack/unpack в виде return conNull()/false. Т.е. чтобы эти методы ничего не возвращали
2. Корректно прописать в pack переменную, в которую выгружается значение текстового поля, соответственно прописать unpack; при создании поля ввода в диалоге либо использовать diaog.addField() без явного указания Value, либо, если использован dialog.addFieldValue() предварительно чистить данные полученные из кеша по this.getLast().

Какой вариант более правильный? Почему?
PS: Ax4.0

По-моему, наиболее предпочтителен 2-й варинат с небольшим дополнением и без какого-либо шаманства в создании диалога: в unpack() просто анализируйте флаг inPromptUnpack и распаковывайте данные, только если он взведен. Такая логика вроде бы наиболее "прямо" ложится на ваши условия задачи.

Цитата:

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

По этому поводу у меня созрел вопрос, который немного отклоняется от темы: всегда ли нужно прописывать pack/unpack? Не в том смысле, что если не сохраняем ничего, то делаем заглушки. А в том, что не надоело ли перекрывать их?

Надоело - даже разработчикам стандартного приложения, и вот в AX 2012 они переделали абстрактные методы pack/unpack в классе RunBase на обычные заглушки В итоге класс RunBase перестал быть асбтрактным, хотя модификатор abstract из его ClassDeclaration не убрали.

Цитата:

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

Да, всегда нужно, исходите из этого.

Разработчики стандартного приложения Аксапты с вами не согласны