Цитата:
Сообщение от
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. вы сломаете поиск по полям. Ну и быстродействие тоже.
Тут вроде все понятно.
В общем, не делайте так.
См. также
Про программистский подход, программистское мышление и стереотипы