Здравствуйте!

Есть необходимость сохранять значение определенного реквизита справочника при открытии формы элемента и проверять его при закрытии этой формы. Что лучше использовать в качестве временного хранилища: переменную или реквизит формы?

переменную
реквизит есть смысл использовать если юзаешь его на форме

(0) а как ты пришёл к такомурешению?

от задачи зависит.
В обычном приложении - переменную
В управляемом - реквизит

(0) управляемая?

в управляемом вроде нет переменных на клиенте

>>сохранять значение определенного реквизита справочника при открытии формы
поменять мозг

(0) "Что лучше использовать в качестве временного хранилища:". Временное хранилище использовать не предлагать?

(6) что тебя смущает?

(0) Проверять надо на сервере или на клиенте?

Записать в ЖР реквизит справочника ПриОткрытии() ?

(10) Не надо, в реквизите формы оно будет лежать пока форма открыта, в ЖР - вечно.

(0) Короч, если надо проверять на сервере факт изменения значения реквизита, то лучше всего это делать через

Если Объект.Ссылка.МойРеквизит <> Объект.МойРеквизит Тогда

В Объект.Ссылка лежит записанное в базе значение, в Объект - текущее значение.

Если надо проверять на клиенте - делай реквизит формы и не парься.

Спасибо!

(6) P.S. Мне нравиться стиль подобных ответов: обидеть человека, но ответ на его, пусть глупый, вопрос не дать при этом. Типа "ну очень умный".

(14) это он для того, чтобы ты себе задал вопрос "что я делаю не так?"

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

(0) Если можно использовать переменную на клиенте, ессно надо её использовать. Реквизит формы - только если на сервер значения передавать надо. Но и тогда можно обойтись передачей переменной через параметры.
Меня, кстати, смущает, как в типовых сделано. Они весь клиентский кэш держат в одной структуре (это ладно) и постоянно гоняют его весь на сервер и обратно. А вот это уже ненормально, ИМХО.

Существует справочник с сотрудниками. При создании нового элемента выполняется проверка на наличие уже созданного сотрудника с заданными ФИО. Если такой существует, то возникает диалоговое окно в режиме вопроса (да/нет): "Создать дубликат?".

Так вот, идея была следующая. Чтобы при редактировании каких-либо других реквизитов (помимо ФИО) существующего сотрудника не вызывать серверную процедуру проверки наличия, нужно зафиксировать факт изменения ФИО. Собственно, для этого и создавались временные объекты: переменная или ревизит формы. Если ФИО не изменялось - то просто пишем без всяких проверок (отсюда -1 серверный вызов). Если же ФИО изменялось - то задаем вопрос, и пишем только при утвердительном ответе (здесь серверный вызов для проверки в любом случае).

Либо я что-то не понимаю в механизме платформы, либо я зря заморачиваюсь с лишним серверным вызовом. Отсюда и возник вопрос.

аллах запрещает сервер при необходимости вызвать?

(18)ПередЗаписью сравнивай данные объекта с данными ссылки и не изобретай веловипедов

(19) :-))) нет, но я хотел избавиться от лишнего вызова таким вот "механизмом"

(20) если сравнивать в событии "ПередЗаписьюНаСервере", то невозможно отобразить диалог вопроса. Поэтому приходиться это делать на клиенте.

(21) а если сравнивать в событии ПередЗаписью?

+(22) точнее, уходить на сервер, сравнивать, а потом наклиентеспрашивать

(22) событие "ПередЗаписью" исполняется на клиенте. Как я получу данные ссылки? Я ведь не смогу выполнить на клиенте код:

Объект.ФИО = Объект.Ссылка.ФИО

(23) да, так можно. Вся соль вопроса в том и состоит. Что дороже: вызвать лишний раз сервер или хранить в переменной/реквизите значение?

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

Wobland, Спасибо большое за интересную и полезную беседу. Буду юзать серверный вызов.

(25)Это такие микросекунды разности что не стоит и огород городить

(28) Не скажи. Серверный вызов через тонкие каналы - это вовсе не микросекунды.

(27) но реально эта ситуация может возникнуть раз в 200 лет. Поэтому вам лучше забить на эту тупую задачу и заняться действительно нужными вопросами.

Ежели разработка идет с прицелом и на мобильные девайсы тоже, то за серверные вызовы стоит побороться.

тут я за без контекста. совсем немного пойдёт

(14) Он ведущий секции "Психология и отношения", собирает себе материал для исследований: необоснованными резкими высказываниями пытается спровоцировать человека на конфликт  и анализирует его последующую реакцию. Он во всех ветках так делает.