Значение display метода по его названию

[Андрей К.]

Доброго времени суток.
Стоит задача: из списка дисплейметодов определенной таблицы(список уже реализован) необходимо выбрать интересующий метод (хранится лишь его название) и выводить значение этого дисплейметода у текущего курсора.

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

[Alex_KD]

Может имеет смысл подобное реализовывать настройками?
Если стоит Галка1, показывать дисплей1
Если стоит Галка2, показывать дисплей2.....

[Андрей К.]

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

[mazzy]

Цитата:

Сообщение от Андрей К.

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

Замечательная дырка в безопасности

Оффтопик про "программисткий подход", извините.
Динамические чекбоксы в неизвестном количестве
Про программистский подход, программистское мышление и стереотипы

[ivas]

Цитата:

Сообщение от Андрей К.

Доброго времени суток.
Стоит задача: из списка дисплейметодов определенной таблицы(список уже реализован) необходимо выбрать интересующий метод (хранится лишь его название) и выводить значение этого дисплейметода у текущего курсора.

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

попробуйте через SysDictClass
вот реализация правда для отчетов

void addString(ReportControl _reportControl, ReportSection _reportSection, common _cursor, SysDictClass _classObj)
{
    ReportStringControl  reportControl = _reportControl;
    str                  s;
    ;

    txt += this.font(reportControl.fontSize(), reportControl.bold(),
                     reportControl.italic(),  reportControl.font());

    if (reportControl.dataField())
    {
        s = _cursor.(reportControl.dataField());
    }
    if (reportControl.dataMethod())
    {
        s = _classObj.callObject(reportControl.dataMethod(), _reportSection);
    }

...................

}

[_scorp_]

static void Job8(Args _args)
{
    LedgerTable lt;
    DictTable dt;
    ;
    select firstonly lt;
    dt = new DictTable(tablenum(LedgerTable));
    info(dt.callObject("taxCode", lt));
 
}

[TasmanianDevil]

Дисплей-метод может возвращать в принципе любой тип примитивный - как там с контролами будет ? Как себя поведет система при попытке контрола преобразовать полученное не родное значение к его родному примитивному типу ?

А вообще - вот :

display AnyType anyMethod()
{
DictTable  tbl = new DictTable(this.tableId);
;
<       >;
return tbl.callObject(<  >, this);
}

P.S. Упс, опередили

[Андрей К.]

Спасибо за помощь!

[Alex_KD]

Цитата:

Сообщение от Андрей К.

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

Помнится там еще из возвращаемого типа берется лейбл, который подставляется в грид.
Интересно кто эти дисплей методы будет выбирать..пользователи?

[macklakov]

Цитата:

Сообщение от Андрей К.

Доброго времени суток.
Стоит задача: из списка дисплейметодов определенной таблицы(список уже реализован) необходимо выбрать интересующий метод (хранится лишь его название) и выводить значение этого дисплейметода у текущего курсора.

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

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

Я бы реализовал это так:
Отмапить таблицы и реализовать на мапе n методов, которые делегируют поведение соответствующим методам таблиц.
На форме показывать мап. На форме же реализовать дисплей, который выберет один из n методов мапы и делегирует ему свое поведение.

В чем приемущество: легко дебажить и код читаемый т.к. нет метапрограммирования. Подозреваю, что и работать будет быстрее
P.S. А еще лучше вывести все n методов в грид и просто управлять видимостью

[mazzy]

Цитата:

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

На форме же реализовать дисплей, который выберет один из n методов мапы и делегирует ему свое поведение.

Эх... Еще одну попытку сделаю, поддержку Alex_KD

Написано "который веберет"
Кто выберет? Пользователь? Как он выберет? По названию метода? А пользователю что-нибудь говорит название метода?

Т.е. на самом деле варианта два:
1. машиноориентированный: Заставлять пользователя выбирать из названий методов. Никаких хелпов, подсказок, описаний. Если пользователю что-то непонятно, то он должен лезть в код. Т.е. этот подход рассчитан на программиста, а не на пользователя.
2. человекоориентированный: сделать обертку над методами, чтобы дать описания, инструкции, хелпы, подсказки и прочую мутотень. Скорее всего, описания должны быть не на программистком матерном, а на пользовательском языке - языке предметной области.

Если все равно делается обертка, то поставленная в исходном сообщении задача НЕ ИМЕЕТ практического смысла.
В обертке все равно будет switch/case по заранее предусмотренным пунктам.

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

[mazzy]

Цитата:

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

Я бы реализовал это так:
Отмапить таблицы и реализовать на мапе n методов, которые делегируют поведение соответствующим методам таблиц.
На форме показывать мап. На форме же реализовать дисплей, который выберет один из n методов мапы и делегирует ему свое поведение.

Если на проекте сознательно выбирается машиноориентированный программистский подход, то я бы предпочел такое решение, нежели динамическое программирование (DictTable-CallObject) без проверок и с постоянной угрозой runtime-ошибок.

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

Цитата:

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

Т.е. на самом деле варианта два:
1. машиноориентированный:
2. человекоориентированный:

Эх... Тоже не удержался

На самом деле, вариант один: программистский! Поскольку все-равно, рано или поздно, но программисту придется лезть в код, чтобы понять, "как оно тикает".

Всякие там "человекоориентированные" настройки - это кажущаяся автоматизация. Количество разных птичек и галочек в Axapte просто безумное. Ни один человек не в состоянии их всех упомнить. Вот и получается такое "гуано". Птичек уж больно много .

А если еще вспомнить про текучку кадров, изменение ТЗ в процессе разработки, постянные авралы и т.д. и т.п., то ... Нет, лучше не вспоминать

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

Я бы рассмотрел задачу написание ОДНОГО метода, но который возвращает разные значения в зависимости от переданных параметров. Ну, или метод-диспетчер (класс-диспетчер), который вызывает соответствующие методы через switch/case. А в качестве параметра использовать BaseEnum, который "человеческим" языком объясняет какой метод надо вызывать.

Чем проще функционал, тем тебе же потом будет легче. Кто же еще снова полезет ковырятся в этом коде

[macklakov]

Цитата:

Сообщение от Владимир Максимов

Количество разных птичек и галочек в Axapte просто безумное. Ни один человек не в состоянии их всех упомнить.

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

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

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

Цитата:

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

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

Так я с этим и не спорю. Я "прицепился" к делению интерфейса на "машино-" и "человеко-" ориентированный в том понимании, как это описал Сергей. Как мне кажется, разница между ними в такой постановке весьма условная.

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Количество разных птичек и галочек в Axapte просто безумное.

Я и не говорил, что стандартная Аксапта - идеал человекоориентированного подхода. И российская, и международная.

Цитата:

Сообщение от Владимир Максимов

Ни один человек не в состоянии их всех упомнить. Вот и получается такое "гуано". Птичек уж больно много

Мне кажется, что птичек мало.
Но они так по-дурацки расставлены

Цитата:

Сообщение от Владимир Максимов

Собственно, написание "человекоориентированного" интерфейса задача сопоставимая с написанием подробной справки по данному функционалу.

А вот здесь категорически не согласен.
Написание человекоориентированного интерфейса - самая простая задача, если понять что же человек на самом деле хочет. Просто решайте ЕГО проблемы, а не свои собственные.

Цитата:

Сообщение от Владимир Максимов

Так я с этим и не спорю. Я "прицепился" к делению интерфейса на "машино-" и "человеко-" ориентированный в том понимании, как это описал Сергей. Как мне кажется, разница между ними в такой постановке весьма условная.

Может быть, не спорю.

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Так я с этим и не спорю. Я "прицепился" к делению интерфейса на "машино-" и "человеко-" ориентированный в том понимании, как это описал Сергей. Как мне кажется, разница между ними в такой постановке весьма условная.

Просто уже неделю приходится заниматься налоговым учетом в Аксапте...
Уровень желчи от этого резко поднимается...

[TasmanianDevil]

Цитата:

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

... лучше захардкодить все реально существующие варианты, чем ваять очередное "универсальное решение" на все случаи жизни...

N-угольные колеса вместо круглых ?
А потом при появлении нового варианта перетачивать на (N+1)-угольное, то бишь допрограммируя ?

Цитата:

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

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

Простите, а чем это отличается функционально от выбора в какой-либо настройке некоего значения Enum'а, по которому в дальнейшем некий суперкласс породит своего потомка с отличным от других функционалом расчета? Программисту - труднее(отсутствует в момент написания проверка на типы и количество аргументов и нет подсветки синтаксиса), консультанту же должно быть по барабану.

Цитата:

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

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

Проблемы консультанта, притом большие, если Enum в настройке он понимает, а класс - нет. Консультант без некоей доли общего программерского багажа по своей предметной части гораздо менее ценен, чем имеющий такой багаж.
Дебажить беда ? Дебажится аки "отче наш", единственная проблема навскидку видится в невозможности увидеть внутреннюю структуру объекта нашего класса, создаваемого через абстрактный объект, в области его жизни, однако при вызове любых методов оного - все как на ладони внутри этих методов. Ежели есть еще какие подводные камни - поведайте, буду весьма благодарен, особенно если на проекте в аттачменте приведете примеры таких проблем.

Цитата:

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

И даже писатель стоящих скилзов не получил. Писать такие модификации не сложно, гордиться здесь нечем

Это, скорее всего, ему решать - поимел он полезный опыт или нет, гордиться ему или стыдиться. Скорее всего поимел, ибо как правило, мысль о подобных "универсализмах" приходит после того как вдоволь "наелся" рутинным допрограммированием и просыпается разумная лень оптимизаторская, что не есть плохо, но вот хорошо ли это - зависит от реализации задуманного.

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

[Lucky13]

Цитата:

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

Написание человекоориентированного интерфейса - самая простая задача, если понять что же человек на самом деле хочет. Просто решайте ЕГО проблемы, а не свои собственные.

А если человек хочет большую красную кнопку "СЧАСТЬЕ"?

[sukhanchik]

Немного ОФФ:
Приятели, занимающиеся 1С (естественно не на внешнем проекте ), рассказывали, как они сделали красную кнопку "Сделать ВСЕ", которая при нажатии чего-то делала (сообщения выдавала), после чего выводилось сообщение - "Все сделано. Повторить?" Естественно - все было муляжом - однако какая была реакция пользователей! Всем очень понравилось - у некоторых даже вопросов не возникло... Вот только руководство озадачилось - а что же кнопка делает? Ну конечно - до скандала доводить не стали - все убрали. Но зато все прониклись, как поучительным примером.