AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 12.12.2016, 21:12   #1  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Всегда ли надо прописывать список переменных в pack?
На днях "сцепились рогами" по сугубо практическому вопросу о том, следует ли всегда прописывать список переменных в pack, даже если этого не требуется с точки зрения работы класса.

Постановка задачи выглядит следующим образом

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

Работоспособность такого класса можно обеспечить двумя способами.

Вариант 1
  • Поставить "заглушку" в pack/unpack в виде return conNull()/false. Т.е. чтобы эти методы ничего не возвращали
  • В методе dialog указать вторым параметром true при вызове super

dialog = super(_dialog, true)

Вариант 2
  • Корректно прописать в pack переменную, в которую выгружается значение текстового поля, соответственно прописать unpack
  • Второй параметр в диалоге при вызове super() оставить в значении по умолчанию
  • При создании поля ввода в диалоге либо использовать diaog.addField() без явного указания Value, либо, если использован dialog.addFieldValue() предварительно чистить данные полученные из кеша по this.getLast()

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

PS: в данном конкретном случае спор шел в рамках Ax4.0, но, думаю, конкретная версия - не принципиальна
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
За это сообщение автора поблагодарили: Maxim Gorbunov (2), dn (1).
Старый 12.12.2016, 21:21   #2  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
интересный вопрос. грамотно поставленный.
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Какой вариант более правильный? Почему?
pack/unpack используется и при передаче объекта между клиентом/сервером.
видимо ради этого случая и было сказано про RunOn = Server. )))

но вариант с заглушкой лично мне кажется ненадежным.
условия могут измениться, люди могут смениться,
и тогда выяснить что "там жеж заглушка" будет намного дороже и дольше,
чем сейчас просто поставить переменные в список макроса и реализовать стандартные и всем понятные методы работы с диалогом.
За это сообщение автора поблагодарили: AP-1055D (1), skuull (1).
Старый 13.12.2016, 00:24   #3  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1234 (44) ++++++++
Регистрация: 11.04.2008
Вариант 1 плох: клиент-сервер таки нужно поддержать, если хочется перфекционизма
Вариант 2 плох: класс можно вызывать из кода, без диалога, если хочется перфекционизма
Вариант 3: там где-то метод можно перекрыть, что-то вроде allowSaveLast (либо метод, либо переменная, объявленная на уровне RunBase). Но, если не ошибаюсь, это поломает передачу параметром клиент/серер. Стоит проверить.
Вариант 4: я бы шел классическим путем:
- сохраняем вашу переменную в pack/unpak как положено.
- в диалоге аналогично, стандартно, чтобы инициализировалось переменной.
- в методе main, принудительно вызываем getLast(), после чего обнуляем переменную. Вы же написали parm метод?
- ну и все. getLast() второй раз не вызывается, так задумано. Будущему программисту вы этим явно покажете, что сделано это осознанно. Универсальность класса сохранится - овцы сыты, волки целы.

Последний раз редактировалось DSPIC; 13.12.2016 в 00:28.
За это сообщение автора поблагодарили: mazzy (2), AlGol (1).
Старый 13.12.2016, 11:58   #4  
makbeth is offline
makbeth
Участник
Аватар для makbeth
КОРУС Консалтинг
 
43 / 52 (2) ++++
Регистрация: 15.05.2007
Адрес: Санкт-Петербург
Цитата:
Сообщение от mazzy Посмотреть сообщение
pack/unpack используется и при передаче объекта между клиентом/сервером.
видимо ради этого случая и было сказано про RunOn = Server. )))
Постановка задачи в данном случае достаточно простая - организовать обработку данных классом на сервере. Решение с изменением свойства класса было принято разработчиком. Решение это не совсем правильное, так как в данном случае pack/unpack для передачи данных класса между клиентом и сервером использоваться не будет, потому что этим значением свойства в принципе запрещается создание экземпляра класса на клиенте. Кому передавать то?
Для правильной работы такого вот механизма минимизации обменов между клиентской (диалоговой) частью и серверной (рабочей) частью RunBase нужно чтобы класс можно было создать как на клиенте, так и на сервере (т.е. CalledFrom = RunOn), а на главный экземпляр на сервере создавать либо в коде, либо, например, через MenuItem с соответствующим свойством.

Цитата:
Сообщение от DSPIC Посмотреть сообщение
Вариант 3: там где-то метод можно перекрыть, что-то вроде allowSaveLast (либо метод, либо переменная, объявленная на уровне RunBase). Но, если не ошибаюсь, это поломает передачу параметром клиент/серер. Стоит проверить.
Не поломает. Передача клиент-сервер использует promptPack/promptUnpack, а SysLastValue - свои saveLast и loadLast. Если уж совсем не хочется сохранять параметры класса, достаточно перекрыть RunBase.lastValueElementName и в нем возвратить пустую строку (по крайней мере в четверке так).

Цитата:
Сообщение от DSPIC Посмотреть сообщение
Вариант 4: я бы шел классическим путем:
- сохраняем вашу переменную в pack/unpak как положено.
- в диалоге аналогично, стандартно, чтобы инициализировалось переменной.
- в методе main, принудительно вызываем getLast(), после чего обнуляем переменную. Вы же написали parm метод?
- ну и все. getLast() второй раз не вызывается, так задумано. Будущему программисту вы этим явно покажете, что сделано это осознанно. Универсальность класса сохранится - овцы сыты, волки целы.
Ну, собственно, да - классика. Только getLast можно вызвать даже в new, чтобы не тащить эту особенность наружу (хоть и в main).
За это сообщение автора поблагодарили: Diman (1).
Старый 13.12.2016, 16:38   #5  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
makbeth, вы чего сказать то хотели в ответ на исходный вопрос:
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Какой вариант более правильный? Почему?
Старый 13.12.2016, 17:19   #6  
dech is offline
dech
Участник
Аватар для dech
Самостоятельные клиенты AX
 
642 / 347 (13) ++++++
Регистрация: 25.06.2009
Адрес: Омск
Записей в блоге: 3
Вопрос интересный, конечно... Сам считаю, если ничего не надо сохранять, то заглушка conNull() вполне себе сойдет. Даже если сменится программист, он вполне сможет понять, что автор не имел намерений сохранять что-либо в классе. Наоборот, сохранение параметров, которые затем затираются, лично на меня наводит легкий ступор.)))
__________________
// no comments
Старый 13.12.2016, 17:27   #7  
dech is offline
dech
Участник
Аватар для dech
Самостоятельные клиенты AX
 
642 / 347 (13) ++++++
Регистрация: 25.06.2009
Адрес: Омск
Записей в блоге: 3
По этому поводу у меня созрел вопрос, который немного отклоняется от темы: Всегда ли нужно прописывать pack/unpack? Не в том смысле, что если не сохраняем ничего, то делаем заглушки. А в том, что не надоело ли перекрывать их? Понятно, что это основной шаблон, на котором держится весь каркас Аксапты. Можно ли как-то усовершенствовать этот механизм, чтобы избавиться от дублирования кода?
Я решил сделать заметочку по этому поводу здесь: http://axforum.info/forums/blog.php?b=8234
__________________
// no comments
За это сообщение автора поблагодарили: mazzy (2), Ruff (5).
Старый 13.12.2016, 20:39   #8  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
1. спасибо за заметочку.

Цитата:
Сообщение от dech Посмотреть сообщение
Всегда ли нужно прописывать pack/unpack?
Цитата:
Сообщение от dech
Но цель была не в этом, а в упразднении пары методов pack/unpack.
2. никогда не испытывал неудобств. всегда тупо перетаскивал методы pack/unpack из своего референсного класса. ну или из tutorial_runbase*...

3. не вижу особого практического преимущества - раньше в списке методов было два "обязательных" метода pack/unpack. а после вашего решения будет два других "обязательных метода". да и макросы остаются.

но в качестве упражнения для ума - хорошая работа.
Старый 13.12.2016, 21:51   #9  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от mazzy Посмотреть сообщение
но вариант с заглушкой лично мне кажется ненадежным.
условия могут измениться, люди могут смениться,
и тогда выяснить что "там жеж заглушка" будет намного дороже и дольше,
чем сейчас просто поставить переменные в список макроса и реализовать стандартные и всем понятные методы работы с диалогом.
Проблема в том, что сама постановка задачи не стандартная. Т.е. сделать "стандартные и всем понятные методы" - не получится. Надо как-то, где-то, но обозначить тот факт, что переменная в pack используется только и исключительно как транспорт между клиентом и сервером. А вот то, что записано в кеше интереса не представляет

Собственно, это и составляет проблему. Список переменных в pack() используется с разными целями

1. Как сохраняемые данные в кеше
2. Как транспорт между экземпляром класса, реализованного на сервере, и формой диалога, открытой на клиенте
3. Как настройки пакетного задания (в данном случае этого нет)

И отделить первую функцию от второй оставаясь в рамках "стандартной" реализации подобных диалогов не получается
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 13.12.2016, 22:00   #10  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1234 (44) ++++++++
Регистрация: 11.04.2008
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Всегда ли надо прописывать список переменных в pack?
Да, всегда нужно, исходите из этого. В чем именно проблема, я уже потерялся - сформулируйте еще разок.
Старый 13.12.2016, 22:18   #11  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от DSPIC Посмотреть сообщение
Вариант 1 плох: клиент-сервер таки нужно поддержать, если хочется перфекционизма
Так он и поддерживается. Просто не создается "двухпалубная" система классов обслуживания формы диалога. Ну, когда к исходникам, созданным на сервере, создается дубликат на клиенте

Т.е. стоим несколько "в раскоряку". Немного избыточный сетевой трафик.

Цитата:
Сообщение от DSPIC Посмотреть сообщение
Вариант 2 плох: класс можно вызывать из кода, без диалога, если хочется перфекционизма
При вызове без диалога и проблемы нет, поскольку нет конфликта между созданием экземпляра класса на сервер и необходимостью открытия формы диалога на клиенте. Вне зависимости от способа реализации

Цитата:
Сообщение от DSPIC Посмотреть сообщение
Вариант 3: там где-то метод можно перекрыть, что-то вроде allowSaveLast (либо метод, либо переменная, объявленная на уровне RunBase). Но, если не ошибаюсь, это поломает передачу параметром клиент/серер. Стоит проверить.
Переменная getLastCalled - определяет, был ли уже вызов метода getLast(). Есть метод по ее установке setGetLastCalled(), но он private. Т.е. из наследников не вызовешь

Т.е. я бы назвал это "хакерским трюком". Очень не стандартное решение. Будет предельно сложным в сопровождении такого класса в будущем

Цитата:
Сообщение от DSPIC Посмотреть сообщение
Вариант 4: я бы шел классическим путем:
- сохраняем вашу переменную в pack/unpak как положено.
- в диалоге аналогично, стандартно, чтобы инициализировалось переменной.
- в методе main, принудительно вызываем getLast(), после чего обнуляем переменную. Вы же написали parm метод?
- ну и все. getLast() второй раз не вызывается, так задумано. Будущему программисту вы этим явно покажете, что сделано это осознанно. Универсальность класса сохранится - овцы сыты, волки целы.
Да, да. "И пастуху вечная память"

Смысл как раз в том, чтобы не делать различных "приседаний" вокруг создания с последующим обнулением переменных. Это как-то напрягает. Создать, чтобы тут же удалить.
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...

Последний раз редактировалось Владимир Максимов; 13.12.2016 в 22:38.
Старый 13.12.2016, 22:26   #12  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от DSPIC Посмотреть сообщение
В чем именно проблема, я уже потерялся - сформулируйте еще разок.


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

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

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

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

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

1. Создаем pack(), но организуем затирание значения полученного из кеша
2. Отказываемся от создания дубликатов класса обслуживания формы на сервере. Т.е. транспорт между клиентом и сервером становится не нужным, как следствие, не нужен и заполненный pack()
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 13.12.2016, 22:33   #13  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1234 (44) ++++++++
Регистрация: 11.04.2008
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
1. Создаем pack(), но организуем затирание значения полученного из кеша
И что смущает в этом подходе?
Старый 13.12.2016, 22:42   #14  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от DSPIC Посмотреть сообщение
И что смущает в этом подходе?
Затирание. Зачем создавать то, что ты использовать не собираешься? Чтобы было?

Кроме того, нужно будет еще как пометить "красными флажками" это место, чтобы будущие поколения программистов случайно не убрали это затирание
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 13.12.2016, 22:57   #15  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1234 (44) ++++++++
Регистрация: 11.04.2008
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Затирание. Зачем создавать то, что ты использовать не собираешься? Чтобы было?

Кроме того, нужно будет еще как пометить "красными флажками" это место, чтобы будущие поколения программистов случайно не убрали это затирание
Цитата:
Сообщение от DSPIC Посмотреть сообщение
- в методе main, принудительно вызываем getLast(), после чего обнуляем переменную.
А что именно смущает? Так сделано по всей системе, сплошь и рядом.
Старый 14.12.2016, 11:13   #16  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
1. Переменную, которую заполняет пользователь в диалоге, сохранять в кеше не надо. Новый вызов диалога - заново заполняем
Мне кажется вот этот момент нужно подробнее разобрать. Если это чисто интерфейса задача, сделать так чтобы значение по умолчанию контрола на диалоге не бралось из кеша, а оставалось пустым/или ещё каким-то, то и не нужно менять принципы работы с кешем, а нужно менять принципы работы с контролом. А именно, просто при создании не инициализировать у контрола значение по умолчанию переменой из кеша, а инициализировать просто пустым значением/или каким там нужно.

Если же задача не сводится только к пользовательском интерфейсу, а затрагивает логику работы/инициализации класса при работе напрямую из кода, то нужно более развернуто формулировать требования. Может быть стоит сделать отдельный специальный конструктор для инициализации класса из кода, если в этом случае нужна другая логика инициализации
Старый 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 Посмотреть сообщение
Да, всегда нужно, исходите из этого.
Разработчики стандартного приложения Аксапты с вами не согласны
Старый 14.12.2016, 14:44   #18  
Weez is offline
Weez
Участник
Axapta Retail User
 
250 / 84 (3) ++++
Регистрация: 18.01.2006
Адрес: Moscow city
А вариант с обычным вызовом pack/unpack, но указывать только CurrentVersion не рассматривали? Чтобы ничего не обнулять и не сохранять. Честно говоря мне проблема тоже кажется надуманной.
__________________
Существует 10 типов людей: одни понимают двоичную систему, другие - нет.
Старый 14.12.2016, 21:24   #19  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от Weez Посмотреть сообщение
А вариант с обычным вызовом pack/unpack, но указывать только CurrentVersion не рассматривали? Чтобы ничего не обнулять и не сохранять.
Поскольку запуск класса на сервере, то в таком виде работать не будет. Точнее, Вы не сможете прочитать значение в getFromDialog(). Всегда будете получать пустое значение поля, как будто пользователь ничего не ввел.
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 14.12.2016, 21:44   #20  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Итого, все-таки большинство склоняется к варианту полного формирования pack/unpack и последующее затирание полученного из кеша значения.

Есть разные варианты того, как именно осуществить это затирание, но это уже детали реализации, зависящие от постановки задачи и личных предпочтений

Я так понимаю, что основная причина в поддержке сериализации? А есть ли смысл в сериализации формы диалога? Т.е. какие проблемы могут возникнуть, если отказаться от сериализации и оставить форму на клиенте, которая напрямую работает с обслуживающим классом на сервере?
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Теги
как правильно

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
axinthefield: Critical issue in SQL Server 2012 Service Pack 1 that could crash your SQL server Blog bot DAX Blogs 0 01.11.2013 01:11
emeadaxsupport: How to disable the Public Sector solution when using Microsoft Dynamics AX 2012 Feature Pack Blog bot DAX Blogs 0 07.08.2012 00:13
emeadaxsupport: Error when upgrading to AX 2012 Feature Pack: The UPDATE statement conflicted with the FOREIGN KEY constraint "FK_ModelElementData_HasModelId_LayerId" Blog bot DAX Blogs 0 20.07.2012 00:11
AX UK: Microsoft Dynamics AX 2009 Management Pack for SCOM 2007 Blog bot DAX Blogs 2 12.08.2009 09:08
chrisfie: Announcing the release of Project Portfolio Server 2007 Service Pack 2 (SP2) Blog bot DAX Blogs 0 24.07.2009 04:20
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 12:16.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.