Сохранение настройки в нескольких файлах (постановка)
SYSDBA (обсуждение | вклад) (Новая страница: «Исторически так сложилось, что код прикладных подсистем мы разбиваем на несколько настро…») |
SYSDBA (обсуждение | вклад) (→Примечания) |
||
| (не показаны 8 промежуточных версий 2 участников) | |||
| Строка 1: | Строка 1: | ||
| − | Исторически так сложилось, что код прикладных подсистем мы разбиваем на несколько настроек по функциональному признаку. Например, Склад-Метаданные, Склад-Данные, Склад-Отчеты и т.п. Объединяющей для этих настроек является конечная настройка ([[Пакет настроек|пакет]]), для которой соответствующим образом проставлены зависимости. При таком подходе размер файлов в формате XML получается слишком большим для нормальной работы через систему контроля версий. | + | Исторически так сложилось, что код прикладных подсистем мы разбиваем на несколько настроек по функциональному признаку. Например, Склад-Метаданные, Склад-Данные, Склад-Отчеты и т.п. Объединяющей для этих настроек является конечная настройка ([[Пакет настроек|пакет]]), для которой соответствующим образом проставлены зависимости. При таком подходе размер файлов в формате XML получается слишком большим для нормальной работы через систему контроля версий. |
| − | + | Можно рассматривать два подхода решения данной проблемы. | |
| − | === | + | # Мы не трогаем существующий механизм сохранения настройки в XML. Вместо этого -- разбиваем существующую настройку на более мелкие и сохраняем их поотдельности. Например, Склад-Отчеты можно разделить на Склад-Отчеты.ТН-2, Склад-Отчеты.ТТН-1 и т.д. Для удобства работы с большим количеством более мелких настроек следует реализовать древовидное представление списка настроек с учетом их зависимостей и функции перемещения объекта из одной настройки в другую. Недостаток этого подхода в том, что придется выполнить большой объем ручной работы по перемещению объектов в существующих настройках. Еще один недостаток (если не будет решена проблема многократной записи одного и того же объекта в разные настройки) это риск перезаписи более новой версии объекта версией из старого файла настройки. |
| + | # Изменяем механизм сохранения и выносим составные части XML в отдельные файлы. | ||
| + | |||
| + | == Вынесение составных частей XML в отдельные файлы == | ||
| + | Настройка будет состоять из главного файла и папки с подчиненными файлами, расположенными в выделенном подкаталоге, например: | ||
| + | |||
| + | Мат склад Макросы.xml | ||
| + | Мат склад Макросы\ | ||
| + | invMat_SaveFrmSettings.vbs | ||
| + | Tgdc_frmInvDocument147872775_59073233SaveSettings.vbs | ||
| + | usrf_acc_delivery_by_account.dfm | ||
| + | |||
| + | В подчиненные файлы может быть перенесена различная информация: | ||
| + | |||
| + | ==== Тег ROW в отдельном файле ==== | ||
Введем максимальный размер тега ROW. При формировании XML будем проверять на этот размер. Если тег получился большего размера, то выносим его содержимое в отдельный файл с именем: | Введем максимальный размер тега ROW. При формировании XML будем проверять на этот размер. Если тег получился большего размера, то выносим его содержимое в отдельный файл с именем: | ||
| Строка 9: | Строка 23: | ||
ИМЯ_НАСТРОЙКИ.РУИД_ОБЪЕКТА.XML | ИМЯ_НАСТРОЙКИ.РУИД_ОБЪЕКТА.XML | ||
| − | Для подключения файла в общий XML мы можем либо воспользоваться [http://www.google.com.by/search?q=xml+file+include механизмом включения файлов], либо реализовать отдельную загрузку при обработке XML | + | Для подключения файла в общий XML мы можем либо воспользоваться [http://www.google.com.by/search?q=xml+file+include механизмом включения файлов стандарта XML], либо реализовать отдельную загрузку при загрузке настройки<ref>Стоит заметить, что при самостоятельной обработке отдельных файлов мы теряем возможность работы с XML файлом, как с единым целым. Например, не сможем выполнить поиск с помощью XQuery или трансляцию с помощью XSLT.</ref>. В последнем случае в тексте настройки прописываем имя файла в атрибуте fname тега ROW: |
<ROW fname="ИМЯ_НАСТРОЙКИ.РУИД_ОБЪЕКТА.XML" /> | <ROW fname="ИМЯ_НАСТРОЙКИ.РУИД_ОБЪЕКТА.XML" /> | ||
| − | === | + | Недостаток данного метода -- большое количество сепаратных файлов для большой настройки. |
| + | |||
| + | ==== Группу тегов ROW в отдельном файле ==== | ||
| + | |||
| + | Аналогично предыдущему, но в файл выгружается не один, а несколько тегов ROW. Имя файла формируем как: | ||
| + | |||
| + | ИМЯ_НАСТРОЙКИ.РУИД_ПЕРВОГО_ОБЪЕКТА.XML | ||
| + | |||
| + | Для подключения в XML используем тег ROWS: | ||
| + | |||
| + | <ROWS fname="ИМЯ_НАСТРОЙКИ.РУИД_ОБЪЕКТА.XML" /> | ||
| + | |||
| + | ==== Исходные тексты скрипт-функций в отдельных файлах ==== | ||
| + | |||
| + | Определяем таблицы и поля, которые хранят исходный код скрипт-функций, DFM экранных форм, отчеты. Каждое такое поле сохраняем без дополнительной разметки в отдельном текстовом файле с именем: | ||
| + | |||
| + | ИМЯ_НАСТРОЙКИ.РУИД_ОБЪЕТА.ПОЛЕ.РАСШИРЕНИЕ | ||
| + | |||
| + | Расширение файла указывается в соответствии с типом записанного в него кода. Например: VBS, DFM, XML и т.п. В теги полей, сохраненных в отдельных файлах, добавляем атрибут fname: | ||
| + | |||
| + | <SCRIPT fname="ИМЯ_НАСТРОЙКИ.РУИД_ОБЪЕТА.script.vbs" /> | ||
| + | |||
| + | Минусы, как и в первом варианте, это большое количество файлов и невозможность использовать стандартные средства поиска по XML и трансформинга. Плюсы в том, что тексты программ хранятся именно как тексты программ, без дополнительной разметки.<ref>Стоит заметить, вычленение тега ROW в отдельный файл -- универсальное решение, которое будет работать как для настроек (кодов программы) так и для данных.</ref> | ||
| + | |||
| + | == Оптимизация XML файла настроки == | ||
| + | |||
| + | Следует уделить внимание оптимизации XML. Например, зафиксировать в спецификациях дефолтные значения флагов MODIFYFROMSTREAM и др. и указывать их для конкретной строки только если они отличаются. | ||
| + | = Примечания = | ||
| + | <references /> | ||
| + | [[Category:Постановка-Отклонено]] | ||
| − | + | __NOTOC__ | |
Текущая версия на 19:30, 4 января 2013
Исторически так сложилось, что код прикладных подсистем мы разбиваем на несколько настроек по функциональному признаку. Например, Склад-Метаданные, Склад-Данные, Склад-Отчеты и т.п. Объединяющей для этих настроек является конечная настройка (пакет), для которой соответствующим образом проставлены зависимости. При таком подходе размер файлов в формате XML получается слишком большим для нормальной работы через систему контроля версий.
Можно рассматривать два подхода решения данной проблемы.
- Мы не трогаем существующий механизм сохранения настройки в XML. Вместо этого -- разбиваем существующую настройку на более мелкие и сохраняем их поотдельности. Например, Склад-Отчеты можно разделить на Склад-Отчеты.ТН-2, Склад-Отчеты.ТТН-1 и т.д. Для удобства работы с большим количеством более мелких настроек следует реализовать древовидное представление списка настроек с учетом их зависимостей и функции перемещения объекта из одной настройки в другую. Недостаток этого подхода в том, что придется выполнить большой объем ручной работы по перемещению объектов в существующих настройках. Еще один недостаток (если не будет решена проблема многократной записи одного и того же объекта в разные настройки) это риск перезаписи более новой версии объекта версией из старого файла настройки.
- Изменяем механизм сохранения и выносим составные части XML в отдельные файлы.
[править] Вынесение составных частей XML в отдельные файлы
Настройка будет состоять из главного файла и папки с подчиненными файлами, расположенными в выделенном подкаталоге, например:
Мат склад Макросы.xml Мат склад Макросы\ invMat_SaveFrmSettings.vbs Tgdc_frmInvDocument147872775_59073233SaveSettings.vbs usrf_acc_delivery_by_account.dfm
В подчиненные файлы может быть перенесена различная информация:
[править] Тег ROW в отдельном файле
Введем максимальный размер тега ROW. При формировании XML будем проверять на этот размер. Если тег получился большего размера, то выносим его содержимое в отдельный файл с именем:
ИМЯ_НАСТРОЙКИ.РУИД_ОБЪЕКТА.XML
Для подключения файла в общий XML мы можем либо воспользоваться механизмом включения файлов стандарта XML, либо реализовать отдельную загрузку при загрузке настройки[1]. В последнем случае в тексте настройки прописываем имя файла в атрибуте fname тега ROW:
<ROW fname="ИМЯ_НАСТРОЙКИ.РУИД_ОБЪЕКТА.XML" />
Недостаток данного метода -- большое количество сепаратных файлов для большой настройки.
[править] Группу тегов ROW в отдельном файле
Аналогично предыдущему, но в файл выгружается не один, а несколько тегов ROW. Имя файла формируем как:
ИМЯ_НАСТРОЙКИ.РУИД_ПЕРВОГО_ОБЪЕКТА.XML
Для подключения в XML используем тег ROWS:
<ROWS fname="ИМЯ_НАСТРОЙКИ.РУИД_ОБЪЕКТА.XML" />
[править] Исходные тексты скрипт-функций в отдельных файлах
Определяем таблицы и поля, которые хранят исходный код скрипт-функций, DFM экранных форм, отчеты. Каждое такое поле сохраняем без дополнительной разметки в отдельном текстовом файле с именем:
ИМЯ_НАСТРОЙКИ.РУИД_ОБЪЕТА.ПОЛЕ.РАСШИРЕНИЕ
Расширение файла указывается в соответствии с типом записанного в него кода. Например: VBS, DFM, XML и т.п. В теги полей, сохраненных в отдельных файлах, добавляем атрибут fname:
<SCRIPT fname="ИМЯ_НАСТРОЙКИ.РУИД_ОБЪЕТА.script.vbs" />
Минусы, как и в первом варианте, это большое количество файлов и невозможность использовать стандартные средства поиска по XML и трансформинга. Плюсы в том, что тексты программ хранятся именно как тексты программ, без дополнительной разметки.[2]
[править] Оптимизация XML файла настроки
Следует уделить внимание оптимизации XML. Например, зафиксировать в спецификациях дефолтные значения флагов MODIFYFROMSTREAM и др. и указывать их для конкретной строки только если они отличаются.
[править] Примечания
- ↑ Стоит заметить, что при самостоятельной обработке отдельных файлов мы теряем возможность работы с XML файлом, как с единым целым. Например, не сможем выполнить поиск с помощью XQuery или трансляцию с помощью XSLT.
- ↑ Стоит заметить, вычленение тега ROW в отдельный файл -- универсальное решение, которое будет работать как для настроек (кодов программы) так и для данных.