Интересно было бы узнать, как в других фирмах решили вопрос хранения переменного числа однотипных значений для одного объекта.
Например. Есть объект, который должны подписать несколько специалистов, но заранее не известно, сколько точно. Может один, а может 10. Соответственно, создать сразу конечное число атрибутов у него будет не совсем правильно. Создам 10 атрибутов, а подписывать придется 12-ти спецам и т.д. Да и атрибут надо не один, а парами на каждого спеца: Дата и ФИО.
В примерах и справке описан механизм хранения массива значений через ";". Но мне это решение не очень то нравится. Надо каждый раз делать анализ строки и контролировать соответствие значений даты и фио двух массивов.
Множественное вхождение атрибутов тоже не очень хороший способ, т.к. в отчетах отображается только один атрибут (произвольный), а не все вхождения.
Кто как выкручивается? Расскажите...
Переменное число атрибутов объекта
Да уж, в такой ситуации остается только выкручиваться. Хорошо сказано.
Есть несколько способов. Во-первых, зачем вообще сохранять их в объекте как атрибуты? Если документ проходит согласование, а затем утверждается, то в объект можно записывать только атрибуты "Утверждаю" и "Дата утверждения"(а то получится, что Бд для подписей предназначена, а не для данных). Все остальные "подписи" необходимы только для того, чтобы утверждающий убедился, что все видели и согласны - т.е. только на момент согласования. А это можно сделать через маршрут - если документ "дошел" до утверждения, значит все согласны. как только один не согласен - на доработку и на окончание работы. А отчет "контроль исполнения" может служить протоколом (листом) согласования.
Во-вторых, когда бывает необходимо кроме "подписи" получить еще и информацию. Тогда, конечно, придется тупо разрешить для типа объекта максимально возможное количетво атрибутов (либо именовать их по смыслу"нормоконтроль", "начальник ТБ", либо просто "подпись1", "подпись2" - в них же все равно будет стоять имя пользователя), а добавлять их к экземпляру объекта по мере надобности.
Вот. Эксплуатируем и тот и другой способ. Может, кто и получше что придумал. Делитесь опытом.
Есть несколько способов. Во-первых, зачем вообще сохранять их в объекте как атрибуты? Если документ проходит согласование, а затем утверждается, то в объект можно записывать только атрибуты "Утверждаю" и "Дата утверждения"(а то получится, что Бд для подписей предназначена, а не для данных). Все остальные "подписи" необходимы только для того, чтобы утверждающий убедился, что все видели и согласны - т.е. только на момент согласования. А это можно сделать через маршрут - если документ "дошел" до утверждения, значит все согласны. как только один не согласен - на доработку и на окончание работы. А отчет "контроль исполнения" может служить протоколом (листом) согласования.
Во-вторых, когда бывает необходимо кроме "подписи" получить еще и информацию. Тогда, конечно, придется тупо разрешить для типа объекта максимально возможное количетво атрибутов (либо именовать их по смыслу"нормоконтроль", "начальник ТБ", либо просто "подпись1", "подпись2" - в них же все равно будет стоять имя пользователя), а добавлять их к экземпляру объекта по мере надобности.
Вот. Эксплуатируем и тот и другой способ. Может, кто и получше что придумал. Делитесь опытом.
Nata
Абсолютно верно утверждение о том, что подписи с промежуточных этапов согласования не нужно хранить в атрибутах. Есть маршруты и вся информация там видна. Тем более никто не будет открывать вложенный объект и смотреть на подписи, если в форме задачи есть вся необходимая информация.
Атрибуты создаются по количеству возможных подписей. Например, "Подпись гл.специалиста", "Подпись нормоконтролера" + соответствующие атрибуты с датами. А если нужно в один атрибут "засунуть" подписи группы лиц, то можно либо создать под это дело специальный атрибут, либо использовать имеющиеся, согласно должности подписывающего. Не бывает же такого, чтобы согласовывать документ с Ивановым, Петровым и Сидоровым независимо от их должности. А потом, что значит, непонятно сколько специалистов должно подписать документ. Для каждого типа документа есть заданный набор подписей. Если нужно, чтобы подписали все начальники отделов, то подписи заносятся в один атрибут "Подпись нач. отдела" либо создаются атрибуты для каждого нач. отдела. Например, "Подпись нач. строительного отдела". А вот для главспецов один атрибут можно использовать коллективно. Независимо от количества атрибутов, совершенно не обязательно их все присваивать объекту. Пусть их будет хоть сотня, но в нужное время нужные подписи всегда можно будет занести в объект. Если же здесь возникает вопрос об отображении их в форме для атрибутов, то здесь можно решить вопрос с помощью динамических свойств элементов формы. Другими словами, если значения у атрибута нет, т.е. NULL, то видимость этого поля = 0. Можно также управлять координатами поля, чтобы заполнение формы было более равномерным. Если какого то поля посередине нет, то сдвигаем все нижележащие поля вверх. Но это, скорее всего, не очень понравится. Проще как-то по другому настроить форму, например, выдавать текст, что подпись такого-то отсутствует. Плюс к этому можно использовать значение статуса. Например, "На согласовании". Это тоже можно анализировать в форме и динамически ее перестраивать.
Теперь о нюансах. Если нужно учитывать несколько дат подписания в одном атрибуте, то надо использовать атрибут типа "Строка". Из строки можно сделать что угодно - дату, число и т.д., лишь бы она была упорядоченной. А второй нюанс - гораздо удобнее использовать (для наглядности) начало новой строки и перевод каретки, т.е. '~r~n'. Здесь '~r' - начало строки, а '~n' - новая строка. Тогда каждая новая подпись или дата будут с новой строки. Визуально, если в форме расположить два поля друг напротив друга, все будет очень хорошо просматриваться.
Собираются подписи в массивы или в одиночные переменные с теми же '~r~n'. Во втором случае значение из переменной попадает в атрибут без предварительной обработки. В первом - нужно организовать цикл и заносить в атрибут каждую строку массива. Можно, опять же, через '~r~n'.
На самом деле возможностей по сбору подписей масса. Нужно только выбрать что больше удобнее пользователям с точки зрения интерфейса и привычки.
С точки зрения организации процесса, отображать нужно не столько подписи, сколько замечания. Чтобы было над чем поработать. Если процесс дошел до конца, то все подписи должны проставиться. "Молчание - знак согласия"!
Атрибуты создаются по количеству возможных подписей. Например, "Подпись гл.специалиста", "Подпись нормоконтролера" + соответствующие атрибуты с датами. А если нужно в один атрибут "засунуть" подписи группы лиц, то можно либо создать под это дело специальный атрибут, либо использовать имеющиеся, согласно должности подписывающего. Не бывает же такого, чтобы согласовывать документ с Ивановым, Петровым и Сидоровым независимо от их должности. А потом, что значит, непонятно сколько специалистов должно подписать документ. Для каждого типа документа есть заданный набор подписей. Если нужно, чтобы подписали все начальники отделов, то подписи заносятся в один атрибут "Подпись нач. отдела" либо создаются атрибуты для каждого нач. отдела. Например, "Подпись нач. строительного отдела". А вот для главспецов один атрибут можно использовать коллективно. Независимо от количества атрибутов, совершенно не обязательно их все присваивать объекту. Пусть их будет хоть сотня, но в нужное время нужные подписи всегда можно будет занести в объект. Если же здесь возникает вопрос об отображении их в форме для атрибутов, то здесь можно решить вопрос с помощью динамических свойств элементов формы. Другими словами, если значения у атрибута нет, т.е. NULL, то видимость этого поля = 0. Можно также управлять координатами поля, чтобы заполнение формы было более равномерным. Если какого то поля посередине нет, то сдвигаем все нижележащие поля вверх. Но это, скорее всего, не очень понравится. Проще как-то по другому настроить форму, например, выдавать текст, что подпись такого-то отсутствует. Плюс к этому можно использовать значение статуса. Например, "На согласовании". Это тоже можно анализировать в форме и динамически ее перестраивать.
Теперь о нюансах. Если нужно учитывать несколько дат подписания в одном атрибуте, то надо использовать атрибут типа "Строка". Из строки можно сделать что угодно - дату, число и т.д., лишь бы она была упорядоченной. А второй нюанс - гораздо удобнее использовать (для наглядности) начало новой строки и перевод каретки, т.е. '~r~n'. Здесь '~r' - начало строки, а '~n' - новая строка. Тогда каждая новая подпись или дата будут с новой строки. Визуально, если в форме расположить два поля друг напротив друга, все будет очень хорошо просматриваться.
Собираются подписи в массивы или в одиночные переменные с теми же '~r~n'. Во втором случае значение из переменной попадает в атрибут без предварительной обработки. В первом - нужно организовать цикл и заносить в атрибут каждую строку массива. Можно, опять же, через '~r~n'.
На самом деле возможностей по сбору подписей масса. Нужно только выбрать что больше удобнее пользователям с точки зрения интерфейса и привычки.
С точки зрения организации процесса, отображать нужно не столько подписи, сколько замечания. Чтобы было над чем поработать. Если процесс дошел до конца, то все подписи должны проставиться. "Молчание - знак согласия"!
-
Alxd
- Активный участник
- Сообщения: 50
- Зарегистрирован: 15 июл 2004, 12:42
- Откуда: Тюмень
- Контактная информация:
Ну конечно, число подписывающихся конечно. Я как бы абстрактно рассматривал задачу.
А то что, подписывающих будет видно в форме шаблона - это бесспорно. Но выполнение работы закончится и данные могут быть удалены. А вот если эти подписи сохранить в атрибутах объекта, то их уже не потерять.
Мне понравилась идея с динамическим изменением свойств полей атрибутов на форме. Здорово. Я не додумался. Теперь знаю как сделаю.
А то что, подписывающих будет видно в форме шаблона - это бесспорно. Но выполнение работы закончится и данные могут быть удалены. А вот если эти подписи сохранить в атрибутах объекта, то их уже не потерять.
Мне понравилась идея с динамическим изменением свойств полей атрибутов на форме. Здорово. Я не додумался. Теперь знаю как сделаю.
-
Anderyt
- Активный участник
- Сообщения: 777
- Зарегистрирован: 15 июл 2004, 13:15
- Используемое ПО: Lotsia PDM PLUS
- Откуда: Тюмень
- Контактная информация:
у нас были похожие проблемы, когда четко не известно заранее, сколько именно и какие пользователи будут подписывать документ. например, чертеж. есть основной штамп, с ним все просто, должен быть весь набор подписей. но это "внутриотдельские" подписи, ГИП и НК... но этот комплект должны согласовать специалисты смежных отделов, а вот как раз их количество и меняется от комплекта к комплекту. нам важно хранить ФИО и дату (хоть это все и есть в истории определенного атрибута, но этого показалось мало) и должность подписавшего. в итоге мы сделали следующим образом.
у листа общих данных текущего комплекта по мере необходимости создаются дочерние объекты, у которых совершенный минимум атрибутов - название смежного подразделения, обозначение комплекта (для порядка), ФИО и дата согласования и состояние (статус). в каждом подразделении последовательно подписывают два человека - рук-ль группы и главный специалист. эти подписи попадают в одну пару атрибутов, у которых даже историю можно не включать. в итоге по набору и состоянию потомков у листа общих данных (состояние можно например посмотреть в настроенной нужным образом вкладке типа "дочерние объекты") можно судить, кто и когда согласовывал комплект... конечно, при этом каждое согласование требует нового экземпляра объекта, что не совсем экономно, но все подписи хранятся всего в двух типах атрибутов, а всего смежных подразделений - около 15.... грубо говоря, выигрыш в кол-ве типов атрибутов - около 15*2 - 2 = 28...
в другом случае, когда требовалось просто иметь список ознакомленных сотрудников, хватило одного строкового атрибута, значение которого формируется с использование знака переноса (~r~n), то есть один в один - пример от LTH..
у листа общих данных текущего комплекта по мере необходимости создаются дочерние объекты, у которых совершенный минимум атрибутов - название смежного подразделения, обозначение комплекта (для порядка), ФИО и дата согласования и состояние (статус). в каждом подразделении последовательно подписывают два человека - рук-ль группы и главный специалист. эти подписи попадают в одну пару атрибутов, у которых даже историю можно не включать. в итоге по набору и состоянию потомков у листа общих данных (состояние можно например посмотреть в настроенной нужным образом вкладке типа "дочерние объекты") можно судить, кто и когда согласовывал комплект... конечно, при этом каждое согласование требует нового экземпляра объекта, что не совсем экономно, но все подписи хранятся всего в двух типах атрибутов, а всего смежных подразделений - около 15.... грубо говоря, выигрыш в кол-ве типов атрибутов - около 15*2 - 2 = 28...
в другом случае, когда требовалось просто иметь список ознакомленных сотрудников, хватило одного строкового атрибута, значение которого формируется с использование знака переноса (~r~n), то есть один в один - пример от LTH..