Runbase vs SysOperation

[trud]

Обычно там делают заполнение параметров от query или наоборот - query от параметров. query кстати в датаконтракт не входит, т.е. ее дополнительно нужно будет передавать.
ну т.е. о чем я и писал, когда имел ввиду развитие framework - существует множество подобных мелочей, которые никто особо не правит и которые сводят все преимущества впустую. т.е. кода у вас получится в итоге больше, с еще большим дублированием чем RunBase

[belugin]

Цитата:

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

query кстати в датаконтракт не входит, т.е. ее дополнительно нужно будет передавать.

Это как? Если в класс/контракт добавить Query parmXXX() или в метод добавить параметр Query xxx оно будет частью контракта?

Вы какую ситуацию имеете ввиду?

[gl00mie]

Цитата:

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

Я думаю, вот эта фраза относилась к тому, что может просто взять, заполнить контракт самостоятельно и запустить операцию. В случае runBase для этого, надо, чтобы сначала автор кода специально придумал и выставил наружу API

Именно так.

Цитата:

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

ну да, в контроллере. Для PurchFormLetter это происходит неявно, в методе construct. причем в методе getDataContractObject
Хотя может это и кривизна конкретной реализации PurchFormLetter, но недавно мы много дней потеряли на поиски этой баги, когда у некоторых пользователей подставлялись старые значения при запуске разноски из кода

Мда, занятно... для прошлых версий, когда создавались наследники RunBase, было хорошим тоном делать для них статический construct(), где после new() еще вызывать getLast(). Смысл был в том, чтобы в стороннем коде можно было дернуть construct(), получить экземпляр класса и при необходимости спокойной выполнять дополнительную инициализацию его через parm-методы, не боясь, что внутри prompt() он все ваши труды перезатрет из SysLastValue. Возможно, разработчики PurchFormLetter в 12-ке решили пойти схожим путем - хотели, как лучше...

Цитата:

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

Обычно там делают заполнение параметров от query или наоборот - query от параметров. query кстати в датаконтракт не входит, т.е. ее дополнительно нужно будет передавать.

Я, может, как-то не так готовлю SysOperation framework, но при необходимости я не гнушаюсь добавлять в DataContract параметры типа Query. Да, при этом нужно делать дополнительную валидацию контракта на предмет передачи "кривого" Query, в котором отсутствуют ожидаемые DataSource'ы. Да, при этом нужно делать некий метод, создающий "Query по умолчанию" - либо в контракте, либо в сервисе. Да, такой вариант в AX 2012 не подходит для сервисов, вызываемых через AIF по http, потому что там DataContract должен быть вообще без малейшей бизнес-логики и ссылок на посторонние типы и классы (хотя это - скорее "особенности" публикации AIF'ом сервисов на IIS). Но в целом, если нужно создать сервис, принимающий на вход Query и запускаемый пользователем интерактивно, а не извне через http, по-моему, Query вполне себе может быть частью контракта. Или речь про какие-то стандартные контракты, а не "вообще"?..

[trud]

Цитата:

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

Я, может, как-то не так готовлю SysOperation framework, но при необходимости я не гнушаюсь добавлять в DataContract параметры типа Query. Или речь про какие-то стандартные контракты, а не "вообще"?..

Ну мы обсуждаем операции, для которых есть диалог пользователя(обычный режим запуска), плюс возможность эту же операцию запустить из кода. Разве если вы добавите в DataContract parmQuery, этот Query появится в диалоге в интерактивном режиме запуска?

[belugin]

Цитата:

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

Ну мы обсуждаем операции, для которых есть диалог пользователя(обычный режим запуска), плюс возможность эту же операцию запустить из кода. Разве если вы добавите в DataContract parmQuery, этот Query появится в диалоге в интерактивном режиме запуска?

Да.

[Raven Melancholic]

Цитата:

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

Да.

А это появилось в 365?
В DAX2012 такое не встречалось (правда не сильно искал), в ней, как правило, дополнительный атрибут AifQueryTypeAttribute используется. Ну и для SRS отчетов свой механизм с запихиванием Query в Map и публикациейDataMember с типом Map.

[belugin]

Цитата:

Сообщение от Raven Melancholic

А это появилось в 365?
В DAX2012 такое не встречалось (правда не сильно искал), в ней, как правило, дополнительный атрибут AifQueryTypeAttribute используется. Ну и для SRS отчетов свой механизм с запихиванием Query в Map и публикациейDataMember с типом Map.

Про SSRS я мало что знаю. Насколько, я помню, это появилось в 2012.