Сохранение настройки в нескольких файлах (постановка)

Материал из GedeminWiki
(Различия между версиями)
Перейти к: навигация, поиск
(Сохранять исходные тексты скрипт-функций в отдельных файлах)
(Примечания)
 
(не показаны 6 промежуточных версий 2 участников)
Строка 1: Строка 1:
Исторически так сложилось, что код прикладных подсистем мы разбиваем на несколько настроек по функциональному признаку. Например, Склад-Метаданные, Склад-Данные, Склад-Отчеты и т.п. Объединяющей для этих настроек является конечная настройка ([[Пакет настроек|пакет]]), для которой соответствующим образом проставлены зависимости. При таком подходе размер файлов в формате XML получается слишком большим для нормальной работы через систему контроля версий.
+
Исторически так сложилось, что код прикладных подсистем мы разбиваем на несколько настроек по функциональному признаку. Например, Склад-Метаданные, Склад-Данные, Склад-Отчеты и т.п. Объединяющей для этих настроек является конечная настройка ([[Пакет настроек|пакет]]), для которой соответствующим образом проставлены зависимости. При таком подходе размер файлов в формате XML получается слишком большим для нормальной работы через систему контроля версий.  
  
Рассмотрим варианты решений.
+
Можно рассматривать два подхода решения данной проблемы.
  
=== Сохранять тег ROW в отдельном файле  ===
+
# Мы не трогаем существующий механизм сохранения настройки в 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 настройки. В последнем случае в тексте настройки прописываем имя файла в атрибуте fname тега ROW:
+
Для подключения файла в общий 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 в отдельном файле  ====
  
Аналогично предыдущему, но в файл выгружается не один, а несколько тегов ROW.
+
Аналогично предыдущему, но в файл выгружается не один, а несколько тегов ROW. Имя файла формируем как:
  
=== Сохранять исходные тексты скрипт-функций в отдельных файлах ===
+
  ИМЯ_НАСТРОЙКИ.РУИД_ПЕРВОГО_ОБЪЕКТА.XML
  
Определяем таблицы и поля, которые хранят исходный код скрипт-функций, DFM экранных форм, отчеты. Каждое такое поле сохраняем в отдельном текстовом файле безо всякой дополнительной разметки. Имя файла:
+
Для подключения в XML используем тег ROWS:
 +
 
 +
  <ROWS fname="ИМЯ_НАСТРОЙКИ.РУИД_ОБЪЕКТА.XML" />
 +
 
 +
==== Исходные тексты скрипт-функций в отдельных файлах ====
 +
 
 +
Определяем таблицы и поля, которые хранят исходный код скрипт-функций, DFM экранных форм, отчеты. Каждое такое поле сохраняем без дополнительной разметки в отдельном текстовом файле с именем:
  
 
   ИМЯ_НАСТРОЙКИ.РУИД_ОБЪЕТА.ПОЛЕ.РАСШИРЕНИЕ
 
   ИМЯ_НАСТРОЙКИ.РУИД_ОБЪЕТА.ПОЛЕ.РАСШИРЕНИЕ
  
Расширение файла указывается в соответствии с типом записанного в него кода. Например: VBS, DFM, XML и т.п. В теги полей сохраненных в отдельных файлах добавляем атрибут fname.
+
Расширение файла указывается в соответствии с типом записанного в него кода. Например: VBS, DFM, XML и т.п. В теги полей, сохраненных в отдельных файлах, добавляем атрибут fname:
  
Минусы, как и в первом варианте, это большое количество файлов и невозможность использовать стандартные средства поиска по XML и трансформинга. Плюсы в том, что тексты программ хранятся именно как тексты программ, без дополнительной разметки.
+
  <SCRIPT fname="ИМЯ_НАСТРОЙКИ.РУИД_ОБЪЕТА.script.vbs" />
 +
 
 +
Минусы, как и в первом варианте, это большое количество файлов и невозможность использовать стандартные средства поиска по XML и трансформинга. Плюсы в том, что тексты программ хранятся именно как тексты программ, без дополнительной разметки.<ref>Стоит заметить, вычленение тега ROW в отдельный файл -- универсальное решение, которое будет работать как для настроек (кодов программы) так и для данных.</ref>
  
 
== Оптимизация XML файла настроки ==
 
== Оптимизация XML файла настроки ==
  
Так же следует уделить внимание оптимизации хранения данных. Например, указывать флаги MODIFYFROMSTREAM и т.п. на уровне таблицы, а для каждой строки указывать их только в том случае, если они отличаются.
+
Следует уделить внимание оптимизации XML. Например, зафиксировать в спецификациях дефолтные значения флагов MODIFYFROMSTREAM и др. и указывать их для конкретной строки только если они отличаются.
 +
 
 +
= Примечания =
 +
<references />
 +
 
 +
[[Category:Постановка-Отклонено]]
  
[[Category:Постановка]]
+
__NOTOC__

Текущая версия на 19:30, 4 января 2013

Исторически так сложилось, что код прикладных подсистем мы разбиваем на несколько настроек по функциональному признаку. Например, Склад-Метаданные, Склад-Данные, Склад-Отчеты и т.п. Объединяющей для этих настроек является конечная настройка (пакет), для которой соответствующим образом проставлены зависимости. При таком подходе размер файлов в формате XML получается слишком большим для нормальной работы через систему контроля версий.

Можно рассматривать два подхода решения данной проблемы.

  1. Мы не трогаем существующий механизм сохранения настройки в XML. Вместо этого -- разбиваем существующую настройку на более мелкие и сохраняем их поотдельности. Например, Склад-Отчеты можно разделить на Склад-Отчеты.ТН-2, Склад-Отчеты.ТТН-1 и т.д. Для удобства работы с большим количеством более мелких настроек следует реализовать древовидное представление списка настроек с учетом их зависимостей и функции перемещения объекта из одной настройки в другую. Недостаток этого подхода в том, что придется выполнить большой объем ручной работы по перемещению объектов в существующих настройках. Еще один недостаток (если не будет решена проблема многократной записи одного и того же объекта в разные настройки) это риск перезаписи более новой версии объекта версией из старого файла настройки.
  2. Изменяем механизм сохранения и выносим составные части 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 и др. и указывать их для конкретной строки только если они отличаются.

[править] Примечания

  1. Стоит заметить, что при самостоятельной обработке отдельных файлов мы теряем возможность работы с XML файлом, как с единым целым. Например, не сможем выполнить поиск с помощью XQuery или трансляцию с помощью XSLT.
  2. Стоит заметить, вычленение тега ROW в отдельный файл -- универсальное решение, которое будет работать как для настроек (кодов программы) так и для данных.
Персональные инструменты
Пространства имён

Варианты
Действия
Навигация
Инструменты