Grid и display-метод

[Russland]

Здравствуйте!
Помогите разобраться.

Понимаю что вопрос ламерский, но...
Возник вопрос по работе с display-методами. display-метод на гриде.
Итак, как известно, display-методы определяемые на источнике данных формы, имеют источник данных в качестве параметра:
display IventQty method1(MyTable _myTable)

В некоем методе на источнике данных рассчитываются несколько параметров, например:

void calculate(MyTable _myTable)
{
	var1+=_myTable.blahBlah1;
	var2+=_myTable.blahBlah2;
	var3+=_myTable.blahBlah3;
}

Далее накопленные значения var1, var2, var3 необходимо вывести на грид display-методами.

display IventQty displayVar1(MyTable _myTable)
{
	this.calculate(_myTable);
	return var1;
}

display IventQty displayVar2(MyTable _myTable)
{
	this.calculate(_myTable);
	return var2;
}

display IventQty displayVar3(MyTable _myTable)
{
	this.calculate(_myTable);
	return var3;
}

Это шож жеж такое получается? Для вывода этих трёх значений calculate() метод будет три раза вызываться???

Выскажите своё мнение, pls.

[Dron AKA andy]

Он будет вызываться не 3, а 333 раза - при каждом обновлении формы и срабатывании display. В результате получите ерунду.

[Russland]

Цитата:

В результате получите ерунду

хорошо
А как в таком случае избежать множественный вызов рассчитывающей функции?

[EVGL]

Цитата:

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

хорошо
А как в таком случае избежать множественный вызов рассчитывающей функции?

Никак. Но Вы же программист, все-таки. Запоминайте _myTable.RecId в переменной, сверяйте, кешируйте результаты.

[Dron AKA andy]

Ну, для начала предлагаю обсудить не реализацию, а задачу

[Russland]

Задача собственно и обозначена в первом посте.
Если свести её к двум словам, то:
есть некий метод, который рассчитывает сразу несколько параметров.
Эти параметры надо потом отобразить в гриде.
Хотелось бы, чтобы при каждом обращении к строке рассчётный метод вызывался один раз. Однако из-за того, чтобы дисплей-метод на форме корректно отображал данные, ему (дисплей-методу) необходимо передавать источник данных, и каждый раз результат перерассчитывать.

За примером далеко ходить не надо.
Берём первую попавшуюся на глаза форму AssetSum

display AssetDisposalScrap budgetDisposalScrapValue()
{
    return assetSumBudget.disposalScrapValue();
}

AmountMST disposalScrapValue()
{
    this.[B]calc[/B]();

    return disposalScrapValue;
}

Итак, метод calc() дёргают каждый раз при выводе того или иного значения.
Эту тему я завёл только из опасений, что я что-то не улавливаю.
Однако мои худшие предположения подтверждаются.
При выводе параметра, каждый раз будет вызываться рассчётный метод.

[Ed1k]

Цитата:

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

Хотелось бы, чтобы при каждом обращении к строке рассчётный метод вызывался один раз. Однако из-за того, чтобы дисплей-метод на форме корректно отображал данные, ему (дисплей-методу) необходимо передавать источник данных, и каждый раз результат перерассчитывать.

http://www.axforum.info/forums/showt...ht=display+map

[kashperuk]

Array vs Map
Вообще, это похожие структуры - коллекции.

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

Можно выполнить нижеприведенный job для сравнения.
И как говорится, извините, если Ваша Ахапта упадёт из-за Out of Memory во втором случае

static void Job35(Args _args)
{
    Array   arr = new Array(Types::Integer);
    Map     map = new Map(Types::Integer, Types::Integer);
    ;
    map.insert(92332432, 32432);
    print "map inserted";
    pause;
    print map.lookup(92332432);
    print map.exists(32432);
    print map.exists(1);
    pause;


    arr.value(92332432, 32432);
    print "Array inserted";
    pause;
    print arr.value(32432);
    print arr.value(1);
    print arr.exists(250);
    pause;
}

Более того, в DAX 4.0 тип для индекса остался int, в то время, как тип для RecId стал Int64. То есть использовать RecId в качестве индекса на 4ке уже не корректно.

С Map таких проблем нет, так как мы сами указываем тип ключевого поля. и они вставляются последовательно (сортированно), и значение ключевого поля не пугает величиной.

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

Я использую Map, когда необходимо выбрать небольшое кол-во значений. Но это - IMHO.

[Maxim Gorbunov]

Да уж. Ответили бы сначала человеку, а потом бы рассуждали. При чем тут Array?! При чем тут Map?!

Russland, Вы правильный пример нашли (я имеею ввиду форму AssetSum). Только смотрите, метод calc() - это метод класса AssetSum (точнее, одного из двух его наследников). И если в него посмотреть, то увидим:

void calc()
{
    ...

    if (calculated)
    {
        return;
    }

То есть, если метод calc() уже был однажды вызван, повторно рассчитывать значения он не будет. Собственно, в Вашем случае (1й пост), если метод calculate() рассчитывает три значения за один проход, добавьте флаг, и не выполняйте метод, если значения уже рассчитаны.

[Ed1k]

Цитата:

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

Да уж. Ответили бы сначала человеку, а потом бы рассуждали. При чем тут Array?! При чем тут Map?!

Если кешировать дисплейные методы на гриде, то и

Цитата:

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

void calc()
{
    ...

    if (calculated)
    {
        return;
    }

тоже нужно где-то хранить

[belugin]

Цитата:

С Map таких проблем нет, так как мы сами указываем тип ключевого поля. и они вставляются последовательно (сортированно), и значение ключевого поля не пугает величиной.

Вообще интересная тема, сравнить по какому закону растет производительность и объем памяти у Map в зависимости от размера. И сделать гипотезу о механизме реализации. (hashtable?)

[Maxim Gorbunov]

Ed1K, первоначально вопрос о чем был?

Цитата:

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

Здравствуйте!
Помогите разобраться.

...

Это шож жеж такое получается? Для вывода этих трёх значений calculate() метод будет три раза вызываться???

Цитата:

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

хорошо
А как в таком случае избежать множественный вызов рассчитывающей функции?

Цитата:

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

Задача собственно и обозначена в первом посте.
Если свести её к двум словам, то:
есть некий метод, который рассчитывает сразу несколько параметров.
Эти параметры надо потом отобразить в гриде.
Хотелось бы, чтобы при каждом обращении к строке рассчётный метод вызывался один раз. Однако из-за того, чтобы дисплей-метод на форме корректно отображал данные, ему (дисплей-методу) необходимо передавать источник данных, и каждый раз результат перерассчитывать.

За примером далеко ходить не надо.
Берём первую попавшуюся на глаза форму AssetSum
...

Итак, метод calc() дёргают каждый раз при выводе того или иного значения.
Эту тему я завёл только из опасений, что я что-то не улавливаю.
Однако мои худшие предположения подтверждаются.
При выводе параметра, каждый раз будет вызываться рассчётный метод.

Что же касается рассуждений о Map и Array, то и тут Вы изобретаете велосипед. В Аксапте есть стандартное кэширование дисплей-методов.

[AndyD]

Цитата:

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

Что же касается рассуждений о Map и Array, то и тут Вы изобретаете велосипед. В Аксапте есть стандартное кэширование дисплей-методов.

Только работает оно исключительно для дисплейных методов на таблицах

[Ed1k]

Цитата:

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

Ed1K, первоначально вопрос о чем был?

Если вопрос был в том, как получить значение три раза
от трёх неизменяемых параметров не считая три раза, то
display-методы вместе со своим гридом идут лесом, они
здесь не причём.

Цитата:

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

Что же касается рассуждений о Map и Array, то и тут Вы изобретаете велосипед. В Аксапте есть стандартное кэширование дисплей-методов.

на датасорсе нет.

[Maxim Gorbunov]

Цитата:

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

Если вопрос был в том, как получить значение три раза
от трёх неизменяемых параметров не считая три раза, то
display-методы вместе со своим гридом идут лесом, они
здесь не причём.

И тем не менее вопрос был именно об этом.
Кроме того, если посмотреть-таки на форму AssetSum, приведенную в качестве примера, можно заметить, что там и грида-то, вообще-то, нет.

Цитата:

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

на датасорсе нет.

Так что же Вам мешает сделать их на таблице? Кстати, задумывались ли Вы, по какой причине разработчики не стали заморачиваться с кэшированием методов на формах/источниках данных?

[Ed1k]

Цитата:

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

Если вопрос был в том, как получить значение три раза
от трёх неизменяемых параметров не считая три раза, то
display-методы вместе со своим гридом идут лесом, они
здесь не причём.

Цитата:

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

И тем не менее вопрос был именно об этом.

Перечитываем сначала и медитируем над названием темы.

Цитата:

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

Кроме того, если посмотреть-таки на форму AssetSum, приведенную в качестве примера, можно заметить, что там и грида-то, вообще-то, нет.

Это да, нет грида, но

Цитата:

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

Однако из-за того, чтобы дисплей-метод на форме корректно отображал данные, ему (дисплей-методу) необходимо передавать источник данных, и каждый раз результат перерассчитывать.

говорит о том что результат надо пересчитывать от строк датасорса

Цитата:

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

Так что же Вам мешает сделать их на таблице?

Ну... у датасорсовских типа параметр есть, а вы не видите разницы? Расскажите о том как датасорсовские заменять табличными.

Цитата:

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

Кстати, задумывались ли Вы, по какой причине разработчики не стали заморачиваться с кэшированием методов на формах/источниках данных?

И об этом тоже

[Maxim Gorbunov]

Пожалуй, выйду из этой дискуссии. Делайте, как Вам вздумается. Пусть наступает всеобщее 1С

Напоследок:

Дла переноса display-метода с источника данных на таблицу обычно используется подход copy/paste После переноса в методе на таблице все обращения к параметру метода заменяются на this, а сам параметр удаляется.

Методы формы всегда выполняются на клиенте, в отличие от методов таблиц, место исполнения которых можно указать. Таким образом, если Ваш display-метод несет в себе значительный объем вычислений, следует расположить его на таблице и выполнять его на сервере. Логика здесь такая: если display-метод прост и заключается, например, в простом суммировании некоторых полей таблицы, можно распологать его на форме, чтобы не увеличивать без нужды траффик между клиентом и сервером; иначе метод следует располагать на таблице и выполнять на сервере. Разумеется, большой необходимости в кэшировании простых методов нет.

Кстати, создание своего кэша все же имеет смысл, но только в случае edit-методов.

[Ed1k]

Цитата:

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

Дла переноса display-метода с источника данных на таблицу обычно используется подход copy/paste После переноса в методе на таблице все обращения к параметру метода заменяются на this, а сам параметр удаляется.

Любое значение в методе доступное только из датасорса и копипаст отдыхает

[belugin]

1. Вьюхи ограничены по своей функциональности, не все получится туда запихать
2. MironovI часто упоминает о неких глюках, связаннх с виртуальными компаниями

[kashperuk]

Цитата:

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

посмотрите, как вычисляются дисплей-методы на закладке Проводки формы SalesTable (написано EVGL)

Идея: на сервере выполняется 1 метод для каждой строки. Метод возвращает контейнер значений. Которые присваиваются локальным переменным формы. Которые выводятся локальными дисплей-методами формы.

усе

Узкоспециализированное решение, ИМХО.

+ для Grid не катит, а вопрос как раз про это.