Можно ли создать edit-метод в таблице кодом на X++?

[mazzy]

Цитата:

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

Добрый день. В принципе, вопрос в сабже. Можно ли создать динамически из текстовой строки метод в таблице? (как в яваСкрипте, например, при помощи класса Function("текст_метода"))

Знаю, что можно создавать таким образом методы в классах при помощи ClassBuild. На предмет таблиц же Гугл ничего хорошего не выдал.

Мне это нужно для формы с гридом, в котором количество столбцов меняется в рантайме в зависимости от данных в базе. И к каждому столбцу я хочу прикрутить свой edit-метод. не создавать же в самом деле over9000 методов чтоб с запасом было...

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

ох, новое поколение выросло.

1. прямой ответ:
1.1. создавать метод из кода можно
1.2. уже открытая форма новый метод не подхватит - будет работать со старой версией таблицы
1.3. чтобы формы на других компьютерах "поняли", что таблица изменилась, необходимо в АОТ на этих формах нажать "восстановить". тогда клиент перечитает АОТ. это же действие можно сделать и программно. (АОТ кэшируется. и клиенты запрашивают обновления раз в 10-15 минут)


2. ответ по сути: НЕ делайте так
2.1. Вы запланировали "нереентерабельный код".
Другими словами в вашу форму без ошибок сможет зайти только один пользователь. Второй пользователь, зашедший в эту же форму с другими параметрами, тут же "сломает" вашу "красоту". Вы замучаетесь биться с аксаптой и обеспечивать монопольный доступ к форме. монопольный доступ к форме - совершенно бесполезное и абсолютно вредное поведение системы.

2.2. Пользователям будет неудобно работать с "over9000 полей"
Вы сейчас только о себе думаете - как бы вам не программировать много одинакового.
Предположим, вы успешно изнасиловали Аксапту и сделали "универсальный метод". Теперь пользователям нужно будет работать с этими полями. ВСЕМ пользователям. с КАЖДЫМ полем! Они вас проклянут.

а вам все равно придется добавлять признак обязательности, валидацию, лукапы и прочую интерфейсную чешую в код...
только теперь не на простые поля, а на программно созданные edit-fields. Со всеми вытекающими последствиями по трудоемкости отладки и разработки.
вас проклянут те, кто будет поддерживать решение после вас.

2.3. вы сломаете поиск по полям. Ну и быстродействие тоже.
Тут вроде все понятно.


В общем, не делайте так.

См. также Про программистский подход, программистское мышление и стереотипы