есть документ с ТЧ "файлы" в нем 1 реквизит с видом "ХранилищеЗначений"

делаю

о = РеквизитФормыВЗначение("Объект");
о.Файлы.Загрузить(мТЗ);
// тут в о.файлы.файл - нормальный формат хранилища
ЗначениеВРЕквизитФормы(о, "Объект");

о = РеквизитФормыВЗначение("Объект");
// а вот тут в о.файлы.файл - фигня

Как обеспечить хранение хранилищ значений в строках табличной части в управляемой форме?

(1) да, та-же проблема, но решения не вижу

проблема не с получением а с сохранением данных

(1) ты как-то победил?

там же в 0 есть решение. посто не нравится оно ему

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

не нрав переходи на фузину

(6) ты кого на фузину послал ?

:)))

короче сделал так

создал реквизит с типом "произвольный",

ПриСозданииНаСервере()
файлы = Новый ХранилищеЗначений(РеквизитФормыВЗначение("Объект").Файлы.Выгрузить());


ПерезЗаписьюНаСервере
ТекущийОбъект.Файлы.Загрузить(Файлы.Получить())

можно не произвольный а строка
ибо это адрес

(9) я сделал работу без временного хранилища, без создания временных файлов...

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

> есть документ с ТЧ "файлы" в нем 1 реквизит с видом "ХранилищеЗначений"
Это будет жесть, ибо при работе с документом как с объектом в память будет все это вычитываться. В том числе при обращениях через точку.
В БСП же предлагается рабочее решение. Создание служебного справочника для документа с такой необходимостью. А на форме можешь представлять его в виде ТЧ.

А зачем принципиально в ТЧ иметь ХранилищеЗначений? Я использовал стандартный механизм прикрепления файлов к документу, а в строке ТЧ храню ссылку на прикрепленный к документу файл.

(12) > в строке ТЧ храню ссылку на прикрепленный к документу файл
Судя по тому, что ТЧ у ТС называется "Файлы", ему даже этого не требуется.

(11) да все нормально будет...

в массивные выборки эта ТЧ не попадает (физически это отдельная таблица)
в памяти 1 объекта - это пофиг, ТЧ не большие и размер одной картинки не большой, банально 1000 строк по это 0.5 гига памяти, а у меня средний документ это 15...20 строк

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

(15) я при не интерактивном перепроведении не использую объект (и уже давно), я движения формирую по ссылке.

(16) "Навешиваешь" без перезаписи объекта? Интересно. Что ж, не буду учить отца. Хочется заложиться на отсутствие объектного доступа в конфе - закладывайся. А лично я всегда против оверинжениринга, но всегда за профилактику.

(17) штатное проведение то-же работает через Ссылку но при этом отрабатывают все подписки как положено.

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

Кроме того у меня есть возможность делать движения у не проведенных документов, это нужно например для документов которые имеют несколько статусов или например имею согласование

(18) И каким образом срабатывают подписки на запись/проведение документа при отсутствии записи/проведения документа? А если есть запись документа - есть и его чтение.

(19) есть штатное проведение (например из формы) и есть проведение обработками без события записи документа.

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

(20) Я и с первого раза понял. Но потом ты упомянул подписки. А подписки при такой схеме работать не будут.

(0) а зачем ты хранишь картинки прямо в документе? Ну прикрути регистр сведений и напиши к нему API в модуле менеджера. За этот API дёргай из формы документа/модуля объекта

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

(23) чего там нетривиального?
ключ строки - текстовыйУИД
при открытии - чтение из РС в реквизит (ТЧ) формы
при записи - запись в РС

(23) всё там просто. В регистре достаточно двух измерений
- ссылка на документ
- идентификатор строки (УникальныйИдентификатор)
последний пользователю не отображается и генерируется автоматически перед записью документа (если пустой в строке) и всё

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

(26) зачем синхронно-то редактировать? Это только самому себе жизнь усложнять. Храни в памяти и складывай в регистр при записи документа

(27) хранить что-то не в самом документе не очень хорошо, например пометил на удаление документ, что при этом произойдет с записью в регистре?

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

а не типовые действия с документом? например групповое изменение реквизитов?

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

продолжать?

(28) ну разве галочка Ведущее на измерении Документ не решает эту проблему? При удалении документа удалится и запись в регистре.

(28) проблемы надуманные, всё это прекрасно разруливается без какого-либо геморроя

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

(28) проблемы сохранения в регистре уже после окончания редактирования не такие уж громадные,по сравнению с проблемами редактирования.
Что касается удаления,то ведущее измерение решает этот вопрос.
В обмене даже лучше,если что-то отдельно,так как его можно будет передавать только при изменении.
С rls можно вообще не заморачиваться,если сделать запрет на доступ к регистру,и использовать функции,где явно передается ссылка документа,по которой права можно прекрасно проверить.

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