Вопрос, возможно, туповат, но всё же. Имеется отчет для тонкого клиента. Нужно иметь возможность в контексте серверных процедур хранить структуру, в которой несколько ТЗ, схемы компоновки и прочее. Как это оптимальнее делать?
Общая переменная очищается при каждом выходе из сервера на клиент, поэтому не подходит.
Реквизит не подходит, потому что, насколько я понял, ему нельзя присвоить значение типа, которого нет на клиенте, даже если реквизит не выводится на форму для отображения.
Временное хранилище. Не вижу смысла постоянно поднимать хранилище, чтобы обратиться к моим данным.

Как сделать такую простую вещь правильнее?

(0) Храни во временном файле или в РС СохраненныеНастройки

+(1) Или вообще в настройках пользователя, если другим пользователям доступ не нужен

(1),(2), это стеб такой? легче уже во временном хранилище)

(0) ЗначениеВСтрокуВнутр?

(3) Это информация))

(4), думал об этом, но это же похуже временного хранилища будет. Постоянно преобразовывать из значения в строку и обратно...

Неужели в УФ нельзя хранить такие значения без всяких махинаций?

Нет альтернативы переменной? Чтобы не очищалась постоянно

Реквизит формы - альтернатива, другой нет

а, ну параметр Сеанса можно ещё заюзать)

(8) По идее это же вызовет перекачку данных клиент-сервер при каждом серверном вызове.. что вряд ли полезно..

(8), хорошо, можно тогда заставить реквизит хранить типы, которых нет на клиенте? Мне ведь не нужно с ними что-то на клиенте делать. Главное, чтобы на сервере были

(10), проблема в том, что в реквизит нельзя запихнуть структуру с ТЗшками

(12) Это не проблема. ЗначениеВСтрокуВнутр.

(11) ТЗ нет на клиенте, но её можно хранить в реквизите формы.

(9), ну можно тогда уже и регистр специальный сделать. Гулять так гулять)

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

(14), мне нужно хранить структуру, которая содержит помимо всего прочего ТЗ

Правильнее логику будет пересмотреть и уйти от необходимости хранить такого рода данные в памяти во время работы с объектом, имхо

(13), да, но это тоже не выход - постоянно преобразовывать

(17) Можно использовать параметры формы, там может быть произвольный тип.

(19) Преобразование дешевле обходится, чем перекачка

Временное хранилище.

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

можно использовать общий модуль с повторным использованием на время сеанса

(20), но тогда данные очистятся после создания формы. Если сделаю ключевым, то результат будет как с реквизитами - будет ругаться

(22) А если структура меняется?:)

(22), вот! это надо бы обмозговать...

(24), да, меняется )

(21), мне бы как раз без перекачки. Просто чтобы только на сервере и было

гугли ПоместитьВоВременноеХранилище

(26) Сделай не структуру, а ТЗ. В ТЗ могут содержаться другие ТЗ в реквизитах формы.

(24) обновлять. делов то

(30) Так обновляется сразу весь кеш.

(29), нет это архитектурно не верно. У меня именно структура. Плюс, колонки придется все прописывать на форме, а они могут измениться

(32) Ну и программно прописать колонки как бы не проблема. Блин, короче есть 100500 способов, тебе все не нравятся.
Используй временное хранилище, это лучший вариант.

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

(34) Если бы еще там можно было хранить всё что угодно. Так фигвам.. во временное хранилище можно засунуть лишь то, что сериализуется..

(33), ну согласись, они ведь реально не удобны)

Почему переменные очищаются? Ну за что такая хрень ? =(

(35), кстати, да. Что вообще странно. Получается в УФ нельзя хранить, например, настроеный запрос с МВТ

(0) Реквизит формы произвольного типа - сворачивай свои данные в структуру и туда прячь

(38), я же написал уже, что нельзя - ругается

(37) Угу.. вот что мешало фирме 1с сделать "глобальный контекст сеанса", доступный из всех серверных вызовов одного сеанса? Насколько бы это упростило всё..

(40), пусть бы хотя бы переменные не очищали

1с сейчас уходит от несериализуемых объектов
учитесь программировать правильно.

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

(42), и как в данной ситуации будет правильно?

(44) Использовать временное хранилище. В которое, кстати, начиная с 8.3 тоже только сериализуемые данные нужно помещать. Потому что содержание хранилища может между серверами перекидываться при падении.

(45), жесть... в погоню за "тонким" клиентом сделали всё намного "толще"

(46) В угоду "мультисерверности" пожертвовали глобальным контекстом.. "не осилили" прозрачную передачу контекста между серверами..

Но вот почему вдруг ТЗ оказалась несереализуема это большой вопрос

(48), эту тайну знает только Он

(48) ТЗ сериализуется, просто она не поддерживается на клиенте:

Возможен обмен с сервером. Сериализуется. Данный объект может быть сериализован в/из XDTO. Тип XDTO, соответствующий данному объекту, определяется в пространстве имен {http://v8.1c.ru/8.1/data/core}. Имя типа XDTO: ValueTable.

(50) не нужно словам придираться