корректный вызов класса

[kitty]

Нужно написать класс:
он может вызываться по MI с текущей записи формы, а может по выбранным записям из другой формы(имеющей такой же DS как и предыдущая форма). Как корректней писать класс:
1) так. чтобы ему передавать в args.record текущую запись и соответственно, вызывая во второй форме циклично по выбранным:
args.record(Table);
new Menufunction(menuItemActionStr(MyMenuItem), MenuItemType::Action).run(args);. Меня тут смущает то,. что каждый раз содается новый экземпляр класса, что по идее накладно плюс при надобности я не могу обработать все записи в одной транзакции
2) написать так класс,чтобы его можно было 1 раз инициализировать, а потом уже передавать на обработку в цикле записи.
3) воспользоваться временными таблицами, recordSortedList-ами или set с идентификаторами записей

[Dron AKA andy]

Через args.record().datasource() выходите на источник данных и в нем уже перебираете выделенные записи, если они есть, или используете текущую.

[kitty]

текущую, значит, способом 1) ?

Возможен вариант, что класс вызывается из другого класса, где обрабатываются, допустим, закупки, а наш класс обрабатывает накладные. Тогда что делать? Циклично находить накладные по каждой закупке и передавать каждую запись в класс, создавая каждый раз новый экземпляр класса? Или как-нить по-другому? по сути, ситуация как и с формой, но что args.record().datasource() должен указывать? на временную таблицу со всеми отобранными по закупкам накладным?

[Dron AKA andy]

Вам нужно создать иерархию классов, наподобие SalesAutoCreate* (может быть, не очень удачный пример, но ничего другого в голову не идет), написать фабричный метод, возвращающий соответствующего наследника в зависимости от переданной таблицы, и т.д... В двух словах не опишешь.

[mazzy]

Цитата:

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

Меня тут смущает то,. что каждый раз содается новый экземпляр класса, что по идее накладно

Нет, это не накладно.

Цитата:

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

плюс при надобности я не могу обработать все записи в одной транзакции

Вы хотели сказать в одном запросе.
Да, именно так написана вся Аксапта.
Разработчики борются за снижение сложности разработки. За счет уменьшения производительности.

Цитата:

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

2) написать так класс,чтобы его можно было 1 раз инициализировать, а потом уже передавать на обработку в цикле записи.

Нет, так вы нарушаете основные принципы ООП: наследование и инкапсюляция.

За счет чего снижается сложность разработки?
= За счет того, что общий алгоритм (класс родитель) реализует общую часть, а детали и контестно-зависимые вещи передает потомкам.
= Следовательно, потомки могут быть достаточно простыми - каждый из них реализует только свою особенность.

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

Цитата:

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

3) воспользоваться временными таблицами, recordSortedList-ами или set с идентификаторами записей

Не надо.
Вы, похоже, привыкли работать с запросами СУБД.
Почитайте про ООП и применение ООП при работе с СУБД.
Почитайте плюсы и минусы...

И еще: один большой СКЛ-запрос не всегда лучше нескольких маленьких. Особенно в многопользовательской системе. Подумайте над этим.

[mazzy]

Цитата:

Сообщение от Dron AKA andy

В двух словах не опишешь.

О! Точно!

[kitty]

я ,наверное, не очень корректно описала проблему:
спасибо за пример. Мой класс не столь сложен, то есть он обрабатывает записи только одной таблицы(то есть как бы вид записей одинаков). Но, просто, в зависимости от того, откуда вызывается он должен обрабатывать не одну запись, а несколько. Вот я и думаю, как это лучше реализовать. Передавать ему по одной записи на обработку или сразу сделать так, чтобы он мог принимать набор записей (то есть, допустим, передавать ему извне уже заполненную врем таблицу). Хотя, если в одном месте передавать врем таблицу, то, видимо, как вы и сказали, придется делать 2 наследника - один реальные записи перебирает(если допустим со строк формы вызван(у которой ds это нужная нам таблица)), а другой наследник работает с времнной таблицей. Но чот сложно уж больно для такой типичной ситуации. Совсем запуталась =(.

[kitty]

спасибо
на самом деле я тупила. думала, что транзакция

PHP код:

ttsbegin
while select purchTable 
    where bla-bla
{args.record(vendInvoiceJour);
new Menufunction(menuItemActionStr(processCurInvoiceJour), MenuItemType::Action).run(args);. 
}
ttscommit 


не откатится если при очередном вызове класса через MI возникнет исключение. Сейчас провела эксперимент - откатывается.
Значит, буду так вызывать. Спасибо.

[kitty]

а думала так, потому что если на форме кликаешь MI, а в методе clicked написать чо-нить типа

PHP код:

 super(); info('AA'); 


То это AA возникнет на экране не смотря на то, что вызванная по MI обработка не завершилась. Не помню, всегда ли это так работает, или только если по MI вызывается форма ..... Как бы последовательность действий теряется.
Может, объясните, напоследок, почему так происходит и только с формами ли или сам MI тоже так работает? Помню транзакции тоже обрываются, если форму в транзакции открывать. То есть форма будто вообще отдельным потоком выполняется.

[Dron AKA andy]

1. В цикле дергать menuitem необязательно, и даже как-то некрасиво. Можно передать в класс предварительно отобранный select`ом набор записей и перебирать его командой next. И временная таблица тоже не нужна. Посмотрите внимательней на классы, кот. я рекомендовал раньше, напр. SalesAutoCreate_Basket.

2. Если через menuitem открывается форма, то система не ждет, пока форма закроется, и в clicked() после super() выполняются последующие команды. super() сделал свое дело - открыл форму, и ждать ее закрытия ему никто не говорил.