И действительно, как сделать такую задачу не усложняя дальнейшее обновление конфигурации? И вроде есть доп. реквизиты и доп. сведения, но почему же они не могут принимать тип таблицы значений?
В итоге чаще всего используется 2 варианта:
1. Простой способ. Прямо в объекте добавляется таблица, а затем либо программно либо жестко(вручную) выводится на форму.
Минусы. Обновление конфигурации будет требовать соблюдения изменений и повышенной внимательности, чтобы не потерять эти изменения.
Плюсы. Самый простой вариант для разработки, к таблице значений можно обращаться без танцев с бубном, например через запросы.
2. Нормальный вариант, но тоже с доработкой конфигурации.
Добавляется объект с таблицей значений и реквизитом с ссылкой на объект родитель, данная таблица значений выводится, к примеру, через расширение конфигурации на форму основного объекта.
Плюсы. Простое обновление, к таблице значений можно обращаться, например через запросы.
Минусы. Требуется больше предусмотреть различные ограничения на созданный объект а, следовательно, требует определенных знаний. Возможно, потребуется добавление роли\ей и настройки профилей пользователей.
Есть, конечно, еще другие варианты к примеру с хранилищем, но статья не об этом…
Статья, о том, как все-таки хранить таблицу значений в доп. реквизитах, ну или в доп. сведениях.
Уже более полугода держу в голове этот способ, но ни разу его не применял. Вот, наконец, добрались руки. Я не утверждаю, что никто не придумывал данный способ, но на подобное решение я не натыкался. Заранее скажу, вариант не идеален, и сгодится только под определенные задачи.
Самый главный минус это то, что будет использоваться строка неограниченной длины а, следовательно, с поиском в ней будут определенные сложности. Самый главный плюс, объекты в конфигурации не правятся.
Пример продемонстрирую на конфигурации Документооборот 2.1.6.8. Буду использовать дополнительный реквизит, но можно использовать дополнительные сведения. Весь код будет написан в Расширении конфигурации.
Задача:
Сразу говорю задачка больше шуточная для демонстрации метода. Например, нам понадобилось добавить табличную часть «Адекватность контактных лиц», она должна присутствовать в справочнике Контрагенты и содержать колонки: Контактное лицо, Совет (некая рекомендация по общению с контактным лицом), Тип контакта.
1 Добавляем доп. реквизит и называем его к примеру «ТЗ_АдекватностьКонтактныхЛиц».
Я этот реквизит делаю общим для всех видов контрагентов. Тип его будет строка неограниченной длины.
2 Создаем Расширение конфигурации и Дорабатываем форму Контрагентов.
Добавляем реквизиты формы:
— «ДопТЗ» тип ПланВидовХарактеристикСсылка.ДополнительныеРеквизитыИСведения
— ТЗ_АдекватностьКонтактныхЛиц тип ТаблицаЗначений:
КонтактноеЛицо тип СправочникСсылка.КонтактныеЛица
ТипКонтакта тип Строка
Совет тип Строка
Добавляем на форму страницу «ГруппаАдекватностьКонтактныхЛиц» и снимаем видимость.
В данную группу выводим «ТЗ_АдекватностьКонтактныхЛиц»
3 Пишем код.
ПриСозданииНаСервере. Необходимо считать сам доп реквизит напомню мы его обозвали «ТЗ_АдекватностьКонтактныхЛиц», далее прочитать его значение и построить по его значению таблицу значений.
Значение доп реквизита я предлагаю хранить в формате JSON, у кого более старая платформа можно использовать XML.
Процедура ДопТЗ_ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
//Считываем доп реквизит
//ТЗ_АдекватностьКонтактныхЛиц - В моем примере доп реквизит называется так
ДопТЗ = ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения.НайтиПоНаименованию("ТЗ_АдекватностьКонтактныхЛиц");
Если ЗначениеЗаполнено(ДопТЗ) Тогда
//Если нашли свойство тогда делаем страницу с ТЗ видимой
Элементы.ГруппаАдекватностьКонтактныхЛиц.Видимость = Истина;
//Считываем значение доп реквизита
НайденныеСтроки = Объект.ДополнительныеРеквизиты.НайтиСтроки(Новый Структура("Свойство", ДопТЗ));
перЗначение = ?(НайденныеСтроки.Количество() = 1, НайденныеСтроки[0].Значение, Неопределено);
//Если значение прочитали пытаемся прочитать из JSON
Если перЗначение <> Неопределено Тогда
//Читаем JSON
ЧтениеJSON = Новый ЧтениеJSON;
ЧтениеJSON.УстановитьСтроку(перЗначение);
Попытка
ДопДанные = ПрочитатьJSON(ЧтениеJSON);
Исключение
ДопДанные = "";
КонецПопытки;
//Если вернулся массив значит JSON прочитали нормально
//Заполняем ТЗ_АдекватностьКонтактныхЛиц
Если ТипЗнч(ДопДанные) = Тип("Массив") Тогда
Для Каждого СтрокаДД из ДопДанные Цикл
СтрАдекватов = ТЗ_АдекватностьКонтактныхЛиц.Добавить();
//Мы уже зарание знаем какой элемент нужно искать по уникальному идентификатору
СтрАдекватов.КонтактноеЛицо = ПолучитьСсылкуПоGUIDИВидуОбъекта(СтрокаДД.КонтактноеЛицо,"Справочники.КонтактныеЛица");
СтрАдекватов.ТипКонтакта = СтрокаДД.ТипКонтакта;
СтрАдекватов.Совет = СтрокаДД.Совет;
КонецЦикла;
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
//Функция возврата Ссылки по уникальному идентификатору и виду объекта
&НаСервере
Функция ПолучитьСсылкуПоGUIDИВидуОбъекта(GUIDВх,ВидОбъектаВх) Экспорт
Результат=Неопределено;
Попытка
Выполнить("Результат = "+ВидОбъектаВх+".ПолучитьСсылку(Новый УникальныйИдентификатор("""+GUIDВх+"""));");
Исключение
КонецПопытки;
Возврат Результат;
КонецФункции
ПриОткрытии. Программно прячем доп. реквизит. Он хранит JSON, поэтому пользователю особо неинтересен.
&НаКлиенте
Процедура ДопТЗ_ПриОткрытии(Отказ)
Если ЗначениеЗаполнено(ДопТЗ) Тогда
//Ищем на форме нужный нам доп реквизит
//Свойства_ОписаниеДополнительныхРеквизитов - В документообороте, в других конфигурациях скорее всего по другому.
НайденныеСтроки = ЭтаФорма.Свойства_ОписаниеДополнительныхРеквизитов.НайтиСтроки(Новый Структура("Свойство", ДопТЗ));
//Прячем элемент программно
Если НайденныеСтроки.Количество() = 1 Тогда
Элементы[НайденныеСтроки[0].ИмяРеквизитаЗначение].Видимость = Ложь;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
ПередЗаписьюНаСервере. Если ТЗ изменилась сохраняем ее в виде строки JSON в доп. реквизит.
Процедура ДопТЗ_ПередЗаписьюНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)
Если ЗначениеЗаполнено(ДопТЗ) Тогда
//Свойства_ОписаниеДополнительныхРеквизитов - В документообороте, в других конфигурациях скорее всего по другому.
НайденныеСтроки = ЭтаФорма.Свойства_ОписаниеДополнительныхРеквизитов.НайтиСтроки(Новый Структура("Свойство", ДопТЗ));
//Описываем параметры записи и создаем запись JSON
ПараметрыJSON = Новый ПараметрыЗаписиJSON(ПереносСтрокJSON.Нет, " " , Истина, ЭкранированиеСимволовJSON.Нет, Ложь, Ложь, Ложь, Ложь);
ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.ПроверятьСтруктуру = Истина;
ЗаписьJSON.УстановитьСтроку(ПараметрыJSON);
//Создаем массив структур на основании ТЗ_АдекватностьКонтактныхЛиц
МассивАдекватов = Новый Массив;
Для Каждого СтрокаТЗ из ТЗ_АдекватностьКонтактныхЛиц Цикл
МассивАдекватов.Добавить(Новый Структура("КонтактноеЛицо,ТипКонтакта,Совет",
Строка(СтрокаТЗ.КонтактноеЛицо.УникальныйИдентификатор()),
СтрокаТЗ.ТипКонтакта,
СтрокаТЗ.Совет));
КонецЦикла;
//Записываем массив виде строки JSON
ЗаписатьJSON(ЗаписьJSON, МассивАдекватов);
СтрокаJSON = ЗаписьJSON.Закрыть();
//Если ТЗ изменили записываем новое значение доп реквизита
Если ЭтаФорма[НайденныеСтроки[0].ИмяРеквизитаЗначение] <> СтрокаJSON Тогда
ЭтаФорма[НайденныеСтроки[0].ИмяРеквизитаЗначение] = СтрокаJSON;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Комментарии (37)
JYE
25.09.2016 11:29-3Как то мне нужно было настроить обмен с базой 1с с самописной конфой, так там все реквизиты справочников были сделаны таким образом. Жесть была еще та
dsdred
25.09.2016 11:54Каким методом? доп реквизитами или как? Не совсем понимаю как в «самописной конфе» можно что то страшное натворить…
JYE
27.09.2016 11:58Один программист создал конфу, в которой во всех справочниках вместо нескольких реквизитов добавил один строковой реквизит с названием «ХМЛ» и в него сохранял в формате XML то, что нужно по сохранять в отдельных реквизитах (ИНН, КПП, р/с — у контрагента, ставку НДС и цены у товара и прочее). Особенно было весело, когда один и тот же по смыслу тег различался по названию от записи к записи. И еще там была куча проблем с ссылочной целостностью.
dsdred
27.09.2016 14:10Хм… А для чего, он так сделал? Работать с такой конфой же невозможно.
Мне конечно рассказывали про одну контору интересную… Известное у нас частное мед учереждение.
Они карточки пациентов в XML хранят в файлах, а все остальное на 1с.
Кто то так у них решил, что так быстрее данные обрабатываются…
Vlkam1
25.09.2016 11:49Добавляется объект с таблицей значений и реквизитом содержащий объект родитель
Ого, а как же ссылочная целостность?
Вообще это конечно прелесно, что 1С за почти 20 лет разработки своей платформы так и не осилила упростить процесс поддержки доработанных конфигураций, введя хоть какое то подобие ООП. Хотя бы в виде «пользовательских» файлов, автоматически сливамых с основной конфигурацией + перезагрузка функций. Это же элементарно сделать
Такое впечатление, что 1С специально усложняет поддержку, чтобы обеспечивать работой своих многочисленных франчайзиdsdred
25.09.2016 11:52-1Ого, а как же ссылочная целостность?
Я имел ввиду «реквизит с ссылкой на объект родитель», изменил в статье.
Может картинками дополню для наглядности…orakool
25.09.2016 22:47-1Таблица значений (ТЗ) содержит ссылку на контактное лицо. Вместе с этой ссылкой ТЗ помещается в строковом виде в дополнительный реквизит. Затем по какой-либо причине контактное лицо удаляется. Вуаля — строковый реквизит содержит ссылку на несуществующий объект. Это и называется отсутствие ссылочной целостности.
dsdred
25.09.2016 22:52-2А, что предусмотреть то это очень трудно и очистить строку в доп реквизите перед удалением?
И вообще вы часто из конфигурации наглушняк удаляете?
Да я конечно не делал в примере различные проверки, да и цели такой небыло. Была цель просто продемонстрировать механизм вывода, а уж ряшечки навесить можно любые.
К примеру вообще заточить данный механизм под то чтобы ТЗ формировала колонки в зависимости от структуры массива. Но это как говорится уже тянет на платные разработки…orakool
25.09.2016 23:28-1Предусмотреть, конечно, можно. Попробуем прикинуть пути решения такой задачи:
- Можно отловить событие пометки на удаление контактного лица в модуле объекта
- Можно сделать подписку на событие удаления объекта
Или махнуть рукой на отсутствие ссылочной целостности.dsdred
25.09.2016 23:34-2Ну а к примеру обработка для удаления чем плохой вариант. Выбрали из списка контактное лицо и нажали удалить. Это на вскидку… Чаще всего элементы не простой пользователь в базе удаляет а грамотный специалист отличающийся умом и сообразительностью ;)
А вообще в документообороте удалять контактное лицо это ересь честно говоря. С ним договора заключали и история хранится в независимости от того уволился он из сторонней конторы.
dsdred
26.09.2016 07:13А вообще, если серьезно о какой целостности идет речь если ТЗ хранится строкой в формате JSON и в ПриСозданииНаСервере можно поставить проверку на это мероприятие?
igrishaev
25.09.2016 15:41Неправда, в 1с все сущности — объекты. Создавать свои классы не имеет смысла, вы просто расширяете готовые, например, прописываете код нажатия кнопки.
dsdred
25.09.2016 16:50Что не правда? Я не понял претензии…
Я кратко заикнулся про часто используемые методы. Один из них добавить в конфигурацию новый документ\справочник с таблицей и в реквизите документ основание указать ссылку на документ\справочник типовой конфигурации. По этим двум кратко описанным пунктам добавлю картинки для ясности но попозже, я на них не акцентировал внимания.
Далее я подробно расписал как использовать дополнительный реквизит для хранения Таблицы Значения в виде JSON. И как через «Расширения конфигурации» работать с этим реквизитом словно с таблицей.igrishaev
25.09.2016 19:45Я отвечал на фразу выше
что 1С за почти 20 лет разработки своей платформы так и не осилила ..., введя хоть какое то подобие ООП.
dauster
25.09.2016 22:17+1Стесняюсь спросить: чем же хорош данный способ? Он что, не требует вмешательства в конфу (первому варианту это было поставлено в минус)? Можно ли использовать эту таблицу, хранимую в строке, в дальнейшем для анализа данных в запросах (а иначе зачем нам все эти данные)? Нет и нет. Как по-мне, так сплошные минусы.
А за хардкод типа «НайтиПоНаименованию(»ТЗ_АдекватностьКонтактныхЛиц");" вообще надо бить по рукам, уж извините.
dsdred
25.09.2016 22:22Судя по комментариям с Документооборотом не работали, ну по порядочку отвечу.
Стесняюсь спросить: чем же хорош данный способ? Он что, не требует вмешательства в конфу (первому варианту это было поставлено в минус)?
Тем и хорош что не требует вмешательства в конфу, в самом низу на скриншоте это наглядно видно.
Также используя этот метод можно сварганить универсальный способ вывода разных таблиц значений в зависимости от вида документа.
Из двух кратко описанных способов 1 по мне это самый плохой, я лично предпочитаю 2-й способ.
Можно ли использовать эту таблицу, хранимую в строке, в дальнейшем для анализа данных в запросах (а иначе зачем нам все эти данные)? Нет и нет. Как по-мне, так сплошные минусы.
По моему я в статье написал, что это один из минусов способа.
Тем кто работает с конфигурацией Документооборот известны хотелки руководства.
Например создать вид документа «Служебка на командировку» и чтобы в ней присутствовала ТЗ с затратами.
Вы работали с конфигурацией документооборот?
Если под каждый вид добавлять ТЗ в конфигурации это будет жомопа как говориться. Справочник то один, а видов документа много и под каждые могут быть хотелки.
Или к примеру в ERP под номенклатуры с видами похожая история.
В данных ситуациях 1 способ вообще не катит.
А за хардкод типа «НайтиПоНаименованию(»ТЗ_АдекватностьКонтактныхЛиц");" вообще надо бить по рукам, уж извините.
Конкретно тут под данный пример этот хардкор очень даже подходит.
В других случаях запросом можно получить.
Хотелось бы услышать ваш вариант…
Ifal
25.09.2016 22:35А если надо будет, развивать механизм, реализовать, например, отчет по контактным лицам с отбором по адекватности? вам придется сначала пройти весь справочник, подготовить таблицу, поместить ее в запрос и только потом работать как обычно. Все это будет работать до определенного момента (объема данных). Практичности от такого подхода на мой взгляд мало.
dsdred
25.09.2016 22:37-1Я и писал что этот вариант подходит не для всех задач. Для вашей задачи лучше 2 вариант или регистр сведений.
Но повторюсь конкретно для документооборота этот способ очень даже подходит. Зачастую по Внутренним документам разного вида разные пожелания.Ifal
25.09.2016 22:58А при чем здесь документооборот? Видимо, просто, тот, кому вы решали таким образом задачу, хотел просто указывать данные в справочниках или документах и не использовать их в совокупном анализе. Таким образом, этот подход ограничевается областью конкретного элемента, например, печатные формы.
dsdred
25.09.2016 23:20-1В том то и дело что данный вопрос очень часто задают по документообороту.
И чаще всего по справочнику внутренние документы или исходящие документы.
Данные справочники в зависимости от вида документов имеют разные наборы доп реквизитов.
Я именно поэтому продемонстрировал данный пример на Документообороте, хотя конечно не на том справочнике по которому спрашивают.
Я данную задачку ни для кого не делал, я просто решил описать данный метод и за минуту придумал «Шуточное задание». Просто чтобы было на чем продемонстрировать.
ZEEGIN
26.09.2016 02:24Данная статья весьма хороша как яркий пример того, как не надо дорабатывать конфигурации.
Неужели обновление доработанной конфигурации на поддержке сложнее обновления расширения конфигурации?
Да и задача слияния дважды измененных объектов не является сколько-нибудь сложной. Ведь третьичное сравнение поставки, обновляемой и доработанной конфигураций выполняется системой автоматически ;)
dsdred
26.09.2016 07:11Данная статья весьма хороша как яркий пример того, как не надо дорабатывать конфигурации.
Неужели обновление доработанной конфигурации на поддержке сложнее обновления расширения конфигурации?
От чего же? Я описал часто встречаемые и используемые методы и описал метод который позволит хранить ТЗ которое выводится «информативно». Что часто кстати просили именно в Документообороте.
Да и задача слияния дважды измененных объектов не является сколько-нибудь сложной. Ведь третьичное сравнение поставки, обновляемой и доработанной конфигураций выполняется системой автоматически ;)
Мне тут вспомнилось. Примерно с год назад столкнулся с базой которую правил беспощадно программист приклонного возраста работающий до этого только с семеркой. Его услугами пользовались потому, что «дешево». Программист умер, что и для чего там наверчено не сохранилось инфы, так как в конторе тякучка адская. Мало того версия конфигурации и конфигурации поставщика каким то волшебным образом оказались различны.
К чему я? Да вроде все просто и легко, но как такое получается?ZEEGIN
26.09.2016 08:13Была тривиальная задача доработки конфигурации, при котором последующее обновление полуавтоматически накатывалось. Скажем так, это задача на которой юниоров знакомят с системой.
Стало: доработанная конфигурация, решающая проблемы бизнеса и заказчика, но!
1. При изменении в БСП методов хранения или отображения доп. свойств все захардкоденные условия типа: сериализации и десериалихации ровно как и скрытие вывода типовым отображением и вывод своим способом, все это просто перестает быть актуальным и нуждается в полной проработке заново.
2. Теряется ссылочная целостность базы.
3. Теряется возможность обращаться к данным на уровне субд, соответственно и возможность использовать индексы для поиска данных, что на больших системах критично.
4. Фактически задача сравнения и объединения остается, только не для конфигураций, а для расширений.
5. С этой доработкой любому программисту будет необходимо сначала разбираться как это все работает, в итоге время обновление релиза не вами будет выше для заказчика, чем если это сделать нормальным способом (кажется вы сами только что на это ругались).
6. Использование расширения конфигурации не по назначению. Было бы условие того, то ваша конфигурация в сервисе, то решение было бы нежелательным, но приемлимым.
7. Заказчик же наверное попросит не только хранить табличную часть, но и обрабатывать ее, искать данные по сведениям в ней или выводить эти данные в отчете. Потому еще и слишком ограниченное применение и усложнение всех последующих доработок по подобным документам.
P.S. Версия конфигурации поставщика спокойно может отличаться от версии из конфы, читайте правила нумерации форков и технологию разветвленной разработки, если хотите работать с нумерацией версий правильно. Тот же простой пример, вы разрабатываете свою конфигурацию на базе БСП со своей нумерацией, но при этом БСП время от времени обновляете до последнего релиза.
P.P.S Финты ушами при разработке надо делать ориентируясь не на плохие примеры до этого в вашей практике, а на хорошие.dsdred
26.09.2016 09:17Надеюсь пишу в последний раз.
Если читать статью там есть такие фразы:
1 «Заранее скажу, вариант не идеален, и сгодится только под определенные задачи.»
2 «Самый главный минус это то, что будет использоваться строка неограниченной длины а, следовательно, с поиском в ней будут определенные сложности.»
3 «Сразу говорю задачка больше шуточная для демонстрации метода.»
Но так как никто не прочитал из тех то комментирует, а просто посмотрел картинки, началось обсуждение…
Я мог сделать пример с двумя колонками «КолонкаСтрока», «КолонкаЧисло» — по крайней мере так любят делать на большинстве ресурсов, но я решил чуть расширить пример.
Кстати о какой целостной речи идет речь если данные хранятся в виде строки, в формате JSON и в ПриСозданииНаСервере можно поставить проверку на это мероприятие?
Вы не допускаете, что по внутренним документам по разным видам нужна просто информативная таблица? При этом для каждого вида различная…
Еще раз повторюсь, я просто привел пример как можно хранить ТЗ в допе с помощью строки.ZEEGIN
26.09.2016 12:10Конечно. Но лучше не давать таких примеров :)
С архитектурной точки зрения такую задачу правильно решить было бы:
Создать свою подсистему дополнительных табличных частей (не пересекающуюся. БСП) состоящую из плана вида характристик определяющих двумерную адресацию значений (имя таблицы и имя реквизита/ресурса) с указанием типа хранения значения. Для документа создать таблицу значений для хранения этих дополнительных табличных частей. Разворачивать такую двумерную адресацию на скд можно в несколько строк кода в режиме обработки таблицы значений. Отредактировать форму документа или создать связанную форму для отображения табличных частей. Данное решение будет не привязано к последующим обновлениям и система будет легко обновляться, помимо этого решение прозрачно для понимания, контроль целостности выполняется платформой, результаты можно использовать как во встроенном языке так и в запросах, сама база данных остается в третьей нормальной форме.
dsdred
26.09.2016 07:01-1вы серьезно?
В статье же написано «Сразу говорю задачка больше шуточная для демонстрации метода.»
Мне больше нравится конечно, что даже при этом к примеру относятся так будто он куда то внедрен…
PaNo
26.09.2016 09:56Можно прикрутить костыль немного попроще: в конфигурациях на БСП есть регистр сведений «ПользовательскиеМакетыПечати» с ресурсом «Макет», который имеет тип «ХранилищеЗначения», соответственно, туда можно запихнуть целиком ТЗ.
dsdred
26.09.2016 10:01Это я в статье упомянул.
«Есть, конечно, еще другие варианты к примеру с хранилищем, но статья не об этом…»
alyaevav
26.09.2016 12:06Полезность статьи конечно минимальна, но чего все накинулись то, про эту минимальность автор и написал:«Заранее скажу, вариант не идеален, и сгодится только под определенные задачи», то есть вариант одноразовый.
AMaxKaluga
26.09.2016 20:12Потому что, кто-то прочитает и подумает что так и нужно делать и это есть правильно.
Из-за болота вредных советов (просто устаревших советов, мифов, велосипедов и т.п.) по 1С и другим языкам, очень тяжело новичкам двигаться в правильном направлении. Такие статьи и полезны только наличием комментариев, чем такие подходы плохи и чреваты в последующем.
Автору + за решительность публиковать свои достижения и продолжать расти, за битого двух небитых дают.
Melex
26.09.2016 22:16Самое страшное в статье даже не сама идея, она в принципе имеет право на жизнь, но тогда я не вижу существенных отличий от простого форматированого документа с табличкой.
А самое страшное — код. Раз уж вы приводите реальные куски кода из серии копи/паст — то хотя бы оптимизируйте его :)
Вы тут делаете все так, как делать не надо, ваш код можно ужать в несколько раз, и работать он будет на порядок быстрее. Некоторые вещи вообще меня заставляют задуматься над смыслом бытия! Зачем вы ГУИ превращаете в строку, а потом в цикле клиента дергаете сервер каждый раз? Что вам мешает сериализовать само значение справочника?
Зачем вы вообще массив создаете? Возьмите вашу таблицу формы конвертните в ТЗ, а ТЗ сериализуйте — 4 строки кода, и тоже самое при десериализации, всю вашу идею можно уместить в 10 строк полезного кода :)dsdred
27.09.2016 09:29Зачем вы ГУИ превращаете в строку, а потом в цикле клиента дергаете сервер каждый раз? Что вам мешает сериализовать само значение справочника?
Пресловутая ссылочная целостность…
Зачем вы вообще массив создаете? Возьмите вашу таблицу формы конвертните в ТЗ, а ТЗ сериализуйте — 4 строки кода, и тоже самое при десериализации, всю вашу идею можно уместить в 10 строк полезного кода :)
Серелизуйте ТЗ с 2 строками и скажите сколько там в JSON осталось полезных значений, а сколько мусора в виде описания типов?Melex
27.09.2016 18:421. Это не решает проблемы ссылочной целостности, аж вообще никак
2. И что? Смущает объем? Ну так помещайте в хранилище :)
dsdred
27.09.2016 20:52Смущает объем? Ну так помещайте в хранилище :)
Смущает.
С хранилищем думаешь меньше весить будет? там тоже будут хранится типы…
Да и не интересно это, всегда хочется поэксперементировать, что то новенькое попробовать.
JYE
Как то мне