Цитата:
Сообщение от
mazzy
предложи варианты
я говорил о наборе пар <таблица, поле> для редактирования query.
я предполагал что-то сугубо внутренне-программистское. такое что не дается пользователю.
Предлагаю
Для начала, небольшое отступление. Когда я начал программировать в среде X++ я считал "не правильным" создавать временные таблицы в AOT. Логика здесь была такая: данные временные, значит, и все объекты, которые их используют должны быть временными. В том смысле, что они должны быть удалены по окончании работы кода. А объект AOT остается! Т.е. "временный объект" оказывается "постоянным".
В настоящее время, я рассматриваю временные таблицы, как
программный код написанный визуальными средствами. Это позволяет избавится от психологического "затыка".
Так вот, возвращаясь к задаче. Если сама задача заключается в создании/изменении query, то, почему-то вариант создания этого самого query напрямую в AOT не рассматривается в принципе. "По определению". Почему собственно? Думаю, по двум причинам:
1. Тот психологический "затык", который я описал чуть выше
2. В отличие от временной таблицы query можно создать программно
Итого, предлагаю вариант прямого создания Query в AOT. Со всеми предопределенными Range.
=============================================
Ну, хорошо, предположим, "ломка" настолько сильная и не преодолимая, что заставить себя создать объект в AOT - невозможно
. Ладно. Тогда переходим к "программистским" трюкам
Как правило, для построения query создается отдельный метод класса вроде BuildQuery. И вот тут еще один интересный вопрос.
А зачем вообще надо предварительно "запихивать" поля в какое-то промежуточное хранилище, если можно прямо так и писать код создания с явным указанием имен полей? Ну, там
queryBuildDataSource.addRange(fieldnum(...))
Зачем здесь "лишние" посредники? Хотите модифицировать query в классах-наследниках? Да пожалуйста! Есть куча методов для этого - clearRange(), findRange() и т.п.
==============================
Ну, предположим, у нас стоит задача иметь возможность делать query с разными таблицами-источниками. Т.е. одного метода создания - недостаточно. Ну, так создайте несколько методов! Не в одном классе, разумеется, а иерархия классов-наследников, каждый из которых будет работать со своими данными
Это как-раз стандартный подход в Axapta.
===============================
Другими словами, все предложенные решения сводятся к тому, что просто не создается временное хранилище для статических данных. Статические данные сразу используются. Без промежуточных хранилищ
Вот именно про это я и говорил, что бессмысленно рассматривать подобную задачу "вообще". Нужна конкретная постановка задачи в смысле конечной цели использования статического набора.