Как передать параметр из Job-a в Class с возможностью перезаписи?

[mazzy]

Цитата:

Сообщение от Yury J

Я запускаю сценарий (Job) из класса. Но передать значение переменной ... не получается.

static AmountMST ScenarioScript134218100335()

Конечно же не получается, раз вы не объявили значения переменных.
Обратите внимание, что все job'ы имеют аргументы Args _args.
Через них родимых и надо передавать, если уж твердо решили делать через job'ы.

Т.е. вы должны объявить

static AmountMST ScenarioScript134218100335(Args _args)

[Yury J]

Доброго времени суток.
Спасибо большое всем за оперативную помощь!
Проблему решил воспользовавшись помощью DSPIC:
Можно пользовать, например, GlobalCache, передавать\забирать параметры через него.
infolog.globalCache().set
infolog.globalCache().get

Мой тебе, DSPIC респект!
Тему можно закрывать.

Постараюсь по максимуму ответить на ваши вопросы
Михаил Андреев
Это где Вы такое прочитали или сами придумали?
Конструкторы штатные, например, конфигуратор или мастер создания налогового регистра, формируют именно классы.

Я создал свой класс конструктор в 4-ке, который при помощи xppCompiler, freeTxt,treenode,job

        t = infolog.findNode("Jobs");
        j = t.AOTfindChild(jobName);

формировал сам Job с уже "зашитым скриптом".
Для пользователя добавил вставочку где он может объявлять объекты и переменные. А также вставочку где он рисовал свой ко логики.
Сам Job вывается по кнопочке из строк настроек Генератора финансовых ротчетов. Для этого добавлен тип строки "Сценарий". как в конкорде. Вот и все.
Таким инструментом пользователь может строить любую отчетность. Пример был разобран мною выше по коду Jb-а.


sukhanchik

Цитата:

Вообще-то основное правило в Аксапте - посмотри как это уже сделали до тебя и сделай по аналогии. Это я к тому, что все вставки на X++ (например при импорте данных) хранятся в таблице в контейнере. Конечно - код приложения в таблице хранить - это та еще засада, но модифицировать только ради этого класс Application я считаю тоже излишне.
Пусть генерится класс. А чем плох класс? Чем джоб лучше класса? Тем что он лучше виден в АОТе и его легче прибить?
Ну так сделайте у классов некоторый префикс и пусть его будет также легко и непринужденно прибить как джоб.
Можно дальше пойти. Можно создать проект, в который добавлять программно классы, созданные из кода. Тогда эти классы будет прибить еще легче чем джобы.

Со всем согласен.
Но для работы нужен был именно этот вариант решения. Таковы были требования Клиента.
А Клиент, сам понимаешь, всегда прав.
И работа уже выполнена и сдана.
Но только промежуточное значение? как ты и пишешь храyилось в таблице.
Что не есть правильно.
И при высокой плотности обращений падала производительность построения отчета. Кроме прочего отчет еще выводится в Excel.

mazzy

            AOT -  ,    main     .
  .

Ваши подозрения не обоснованы.
Вспомните модуль GALAXY. И Вам много станет понятно.
Или Датчане тоже извращенцы?

mazzy

PHP код:

Конечно же не получается, раз вы не объявили значения переменных.
Обратите внимание, что все job'ы имеют аргументы Args _args.
Через них родимых и надо передавать, если уж твердо решили делать через job'ы.
 
Т.е. вы должны объявить
 
X++:static AmountMST ScenarioScript134218100335(Args _args) 


Спасибо, Сергей!
Я всё это знаю.
Но я пошёл свом путём .

[mazzy]

Цитата:

Сообщение от Yury J

Мой тебе, DSPIC респект!
Тему можно закрывать.

Внизу каждого сообщения есть ссылка "Поблагодарить автора сообщения".
Нажмите и ваш респект отобразится в его профиле.
Пока респект только на словах

Цитата:

Сообщение от Yury J

Вспомните модуль GALAXY. И Вам много станет понятно.
Или Датчане тоже извращенцы?

Да, среди них встречаются те еще затейники, блин.

Цитата:

Сообщение от Yury J

Спасибо, Сергей!
Я всё это знаю.
Но я пошёл свом путём .

Ок.
Цезарь, идущие на смерть приветствуют тебя! (С)

[sukhanchik]

Цитата:

Сообщение от Yury J

Но для работы нужен был именно этот вариант решения. Таковы были требования Клиента.
А Клиент, сам понимаешь, всегда прав.
И работа уже выполнена и сдана.
Но только промежуточное значение? как ты и пишешь храyилось в таблице.
Что не есть правильно.
И при высокой плотности обращений падала производительность построения отчета. Кроме прочего отчет еще выводится в Excel.

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

А вот в отношении правоты Клиента готов поспорить. Конечно, при уже оттестированном коде, который генерит джобы - ломать все - не есть правильно.
С одной стороны.
С другой стороны, если этот функционал будет еще активно развиваться - то лучше сразу его сломать.
Работал я по принципу - Клиент всегда прав. Оказалось - что Клиент-то на самом деле не всегда прав. Если исключить откровенную дурость - то всегда можно прийти к консенсусу, который выродится в минимальное кол-во изменений.
В противном случае - работа выльется в то, что придется туда-сюда переделывать, а Клиент будет недоволен - что никак все не сделаете.
А в случае откровенной дурости - надо танцевать от позиции "В Аксапте это невозможно". Это хорошо действует, даже если это технически возможно.

В общем-то "Жираф большой ему видней" - так что если Вы решили свои задачи - значит для Вас все ок.

[oip]

Цитата:

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

А в случае откровенной дурости - надо танцевать от позиции "В Аксапте это невозможно". Это хорошо действует, даже если это технически возможно.

Я обычно говорю "в Аксапте это сделать очень трудоемко" и говорю свою временную оценку (несколько завышенную) и о последствиях предупреждаю, чтобы уж не сильно обманывать. Действует. И всех учу не работать слепо по принципу "клиент всегда прав". Клиент НЕ всегда прав. А так полностью согласен. Более того, я не верю, что у клиента было требование сделать именно джоб. Думаю, клиенту надо чтобы работало. А уж как это будет сделано - не его забота.

Оффтоп: Аналогично, когда программист читает ТЗ, то тоже не надо считать, что "консультант всегда прав, поэтому раз так написано в задании, то надо делать именно так." А то часто тут на форуме проскакивает "это не моя вина, мне так написали в ТЗ". Если в ТЗ написано не так, как надо, необходимо сказать об этом постановщику и найти компромис.

Upd. http://www.amand.ru/modules/wordpres...ves/67#more-67

[Logger]

Цитата:

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

Я обычно говорю "в Аксапте это сделать очень трудоемко" и говорю свою временную оценку (несколько завышенную) и о последствиях предупреждаю, чтобы уж не сильно обманывать. Действует. И всех учу не работать слепо по принципу "клиент всегда прав". Клиент НЕ всегда прав. А так полностью согласен. Более того, я не верю, что у клиента было требование сделать именно джоб. Думаю, клиенту надо чтобы работало. А уж как это будет сделано - не его забота.

Оффтоп: Аналогично, когда программист читает ТЗ, то тоже не надо считать, что "консультант всегда прав, поэтому раз так написано в задании, то надо делать именно так." А то часто тут на форуме проскакивает "это не моя вина, мне так написали в ТЗ". Если в ТЗ написано не так, как надо, необходимо сказать об этом постановщику и найти компромис.

Upd. http://www.amand.ru/modules/wordpres...ves/67#more-67

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