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

[Vasiliusis]

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

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

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

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

[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. вы сломаете поиск по полям. Ну и быстродействие тоже.
Тут вроде все понятно.


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

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

[Vasiliusis]

Цитата:

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

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

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


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

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

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

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


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

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

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

[TasmanianDevil]

Цитата:

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

маццы

Так Маззи еще никто не называл

[Vasiliusis]

Цитата:

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

Так Маззи еще никто не называл

Ну по-английски читается именно так. Никто же не произносит Pizza как "пизза". Все говорят "Пицца".

[Владимир Максимов]

Цитата:

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

проклятия меня не пугают, еще не один политик от проклятий не сдох лол

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

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

[Maxim Gorbunov]

Посмотрите в сторону FormTableControl

[belugin]

Цитата:

Сообщение от Maxim Gorbunov

Посмотрите в сторону FormTableControl

Во времена ax3 эта штука глючила страшно

[pitersky]

Цитата:

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

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

а можно поподробнее про условия задачи? из того, что вы написали, я лично никак не вижу необходимости предлагаемого действа

[ax_mct]

Подозреваю что вместо вертикали надо горизонтально.
То есть те сущности которые якобы требуют столбцов представить в виде строк.
А ! В ! С
на
А
В
С
И почему то мне кажется что будет правильней в любом случае.
Так как динамические столбцы это изврат независимо от АХ.

[dech]

Цитата:

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

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

Меня терзают смутные сомнения... Вы случайно раньше на Delphi+Firebird не работали?

[Vasiliusis]

Цитата:

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

Меня терзают смутные сомнения... Вы случайно раньше на Delphi+Firebird не работали?

не работали

[Vasiliusis]

Цитата:

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

а можно поподробнее про условия задачи? из того, что вы написали, я лично никак не вижу необходимости предлагаемого действа

ок, значится так:

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

Т.е. мне надо вертикальную структуру хранения данных для пользователей на форме сделать горизонтальной (динамически добавить в грид на форме столбцы, соответствующие строкам в таблице). Ну ладно, это я еще смогу сделать, знаю где искать.

Главная цель состоит в том, чтобы потом как-то обработать данные, вводимые пользователем в ячейки таких динамических столбцов. Единственное решение, которое видится - edit-метод. Но из-за того, что количество этих столбцов переменное я не могу написать edit-методы заранее. Вот я и спросил, можно ли генерить edit-методы (на уровень DataSource например) при добавления столбцов в грид прям в рантайме?

не, можно конечно написать этих edit-методов с запасом, штук 30, но ведь это не годится... вот как-то так

[Vasiliusis]

Цитата:

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

Подозреваю что вместо вертикали надо горизонтально.
То есть те сущности которые якобы требуют столбцов представить в виде строк.
А ! В ! С
на
А
В
С
И почему то мне кажется что будет правильней в любом случае.
Так как динамические столбцы это изврат независимо от АХ.

надо из вертикального хранения в БД сделать горизонтально на форме

[mazzy]

Цитата:

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

надо из вертикального хранения в БД сделать горизонтально на форме

facepalm!

Контрольные вопросы:
это надо пользователям? а кому? а пользователи то что хотят?

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

[Vasiliusis]

Цитата:

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

facepalm!

Контрольные вопросы:
это надо пользователям? а кому? а пользователи то что хотят?

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

Мацци, контрольные ответы: да. всем. хотят так.

Ну просто в мире программирования бывают сложные задачи,понимаете

[macklakov]

Цитата:

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

Мацци, контрольные ответы: да. всем. хотят так.

Ну просто в мире программирования бывают сложные задачи,понимаете

Сдается мне это кто-то из старичков решил прикинуться малолетним дебилом и потроллить почтенную публику.
И у меня есть неопровержимые доказательства! Если верить профилю, у персонажа за плечами 3 года разработки. К 3-му году разработчик при одном упоминании о таком решении непроизвольно тянется к ведру с розгами, дабы выпроть негодника.

[sukhanchik]

Кстати, нормальное желание для тех, кто:
1. Привык к таблицам в Excel (в т.ч. сводным)
2. Знает, что такое перекрестные запросы (штука, не поддерживаемая АХ).

Т.е. все это похоже на требования к BI-системе только в сильно упрощенном виде.
Соответственно, и реализовывать все это проще с использованием ActiveX-компонент, имеющих отношение к BI. Самый наипростейший вариант (правда немного устаревший) - компонент SpreadSheet из пакета Office Web Components (OWC). Вариант потяжелее - это непосредственно Excel.
Самое сложное из всего этого - приучить пользователей, что если вывести данные так еще и можно (обычный отчет в Excel, где на скрытом листе данные, удобные для представления в АХ, а на отображаемом листе - сводная таблица, опирающаяся на эти данные), то вот обеспечить такую форму для ввода - это сильно сложно. Сильно = затраты на реализацию неоправданно высоки по сравнению с тем, чтобы приучить народ вводить в другом виде, но иметь отчет.

В мире большого объема данных такого рода отчет делается в кубах с помощью какого-либо средства просмотра (Excel, SSRS, QlickView и т.д.). А вариант "по-деревенски" - это выгрузка данных в Excel на скрытый лист с отображением сводной таблицы на другом листе

[S.Kuskov]

Цитата:

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

Главная цель состоит в том, чтобы потом как-то обработать данные, вводимые пользователем в ячейки таких динамических столбцов. Единственное решение, которое видится - edit-метод

А редактировать непременно нужно в самом гриде? А если для целей редактирования отправлять пользователя в отдельное окно? Вообще нужно донести до пользователей что писать и читать данные не обязательно в одном и том же виде, не накладывает система такого ограничения.

[mazzy]

Цитата:

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

Мацци, контрольные ответы: да. всем. хотят так.

Ну просто в мире программирования бывают сложные задачи,понимаете

Бггг.
Вы упорно не понимаете, что пользователи не живут в мире программирования.
Ну, ок.
Удачи.