Показать сообщение отдельно
Старый 14.12.2016, 11:17   #17  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Есть класс - наследник от 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 Посмотреть сообщение
Да, всегда нужно, исходите из этого.
Разработчики стандартного приложения Аксапты с вами не согласны