создать новую тему раскрыть все
 
Если очень кратко, то вопрос таков: нужно ли делать поддержку шаблонов XSL в выгруженном файле XML?
 
Более детально ситуация выглядит так: во время экспорта программа формирует файл XML, который в дальнейшем может быть использован для импорта. Если добавить к этому файлу ссылку на шаблон XSL, то из сформированного файла можно будет получить любой отчет силами программиста, владеющего технологией XSL.
 
Поскольку выгрузка в XML делается плагином, мне не хотелось бы добавлять в интерфейс пользователя дополнительное поле для выбора шаблона, потому что это поле не будет использоваться другими плагинами, например, для выгрузки в Excel.
 
В общем, у меня появилась такая идея: когда пользователь выбирает название файла, в который должен быть сохранен выгружаемый XML, программа проверяет, есть ли в папке, в которую сохраняется файл шаблон с тем же названием или нет. Если нет, то выгружается просто файл без ссылки на XSL, если такой шаблон найден, то в выгружаемый файл добавляется ссылка на него.
 
Или вообще не заморачиваться поддержкой шаблонов?
 
Пользователь запускает мастер экспорта и указывает, что ему необходим экспорт в файл C:\My data\ex-result.xml
 
Во время выгрузки программа проверяет, есть ли в папке C:\My data файл ex-result.xsl.
 
Если есть, в экспортируемый файл добавляется строчка
<?xml-stylesheet type="text/xsl" href="ex-result.xsl"?>
 
Если шаблон не найден, ссылка на него не добавляется.
 
Нужна такая функциональность или достаточно просто выгружать всегда "голый" XML без ссылок на шаблоны?
 
... но было бы очень удобно.
 
Заранее спасибо!
 
...у неподготовленного пользователя. Вот вариант сценария: кто-то сделал для него шаблон, который генерирует нужный отчет. До тех пор пока пользователь просматривает этот отчет на своем компьютере, все в порядке. Но если пользователь попытается куда-то отправить этот отчет и забудет вместе с отчетом отправить файлик шаблона, то принимающая сторона не сможет его просмотреть. И наоборот, рискует увидеть в xml-документе то, чего ему показывать не следовало бы.
свернуть/развернуть ветвь Fwd: (Без темы) [BION 22/06/2010 16:05] # написать ответ
 
Ну в общем-то, принимающая сторона и так может увидеть все что в ХМЛе. А по поводу шаблона, опять же, тут не принципиально, главное - был бы структурированный ХМЛ, а потом хоть потоп. При желании, как минимум можно наваять простенький скрипт для подключения нужных темплейтов, а кому нужно - отдельное приложение для построения репортов.
Так что вы правы, ссылка на шаблон может быть лишней.
свернуть/развернуть ветвь И я за отсутствие ссылки [Дим(м) 23/06/2010 19:41] # написать ответ
 
Иначе, почему бы тогда не сделать ещё один шаг и не сохранить сразу готовый отчёт (применить этот самый xsl к xml и сохранить уже сам результат)?
Это решит и проблему с "чего показывать не следовало", например.
 
Вообще, думаю, очень немногие будут пользоваться экспортом в xml.
Если API для плагинов экспорта/импорта будет достаточно гибким, то появятся более "высоко-уровневые" плагины, которыми большинство и будет пользоваться.
свернуть/развернуть ветвь Резонно. [Dervish 25/06/2010 14:25] # написать ответ
 
Ладно, уберу этот код, я его уже написал.
 
В конце концов, экспорт/импорт преследует несколько иную задачу, чем подготовку отчетов. Просто уж больно велик был соблазн "навесить" дополнительную функциональность малыми силами.
 
Мало того именно настраивать разные.
свернуть/развернуть ветвь Я вот подумал ещё раз... [Дим(м) 06/07/2010 21:55] # написать ответ
 
Может, сделать немного иначе:
- при экспорте AC вставляет во все XML файлы ссылку на "default.xsl"
- если такого файла в папке экспорта нет, то AC сохраняет под этим именем какой-то более-менее нормальный стандартный шаблон
 
Тогда пользователь может:
а) модифицировать эту "заготовку" под свои предпочтения
(причём, это автоматически применится ко всем экспортированным файлам в этой папке)
или б) легко изменить в конкретном файле ссылку на свой собственный "специальный" (для этого файла) шаблон
и в) сразу смотреть нормально оформленный результат экспорта, даже если ничего не понимает в XSL
 
===
Так же пришли в голову такие мысли:
- загрузка курсов валют из интернета - это ведь, по сути, тот же импорт - может, и сделать универсальные плагины импорта, а не отдельно "импорт", отдельно "курсы"?
- бэкапы тоже можно сохранять в XML формате Well
- да и для самой базы можно использовать "зазипованный" XML Well хотя, наверное, это негативно скажется на скорости загрузки, надёжности и пр.
 
И все-таки, я убрал из кода экспорта генерацию ссылок на шаблон. В перспективе переработка отчетов, их можно будет сделать выгружаемыми в xml и там уже шаблоны будут прописаны. Кстати, была мысль еще выгружать отчеты в MS Word, но пока она только на уровне идеи.
 
===
 
Собственно, никто не запретит сделать плагин импорта, качающий информацию из интернета. Вот только, в мастере импорта настроек будет минимум касательно валют, а перегружать мастер импорта настройками по курсам не хотелось бы: будет очень напряжно проходить в мастере 10 шагов, чтоб добраться до самого импорта.
 
Сейчас я сделал уже экспорт данных в формат OpenOffice Calc, там документ как раз является xml-файликами в zip-архиве, так что мне довелось "пощупать руками" эту технологию. И вот что могу сказать по итогам:
 
1. Огромная экономия места. ZIP сжимает файлы очень эффективно, в итоге выгруженные данные в разы меньше самого файла данных. Производит впечатление.
 
2. Запись xml в zip-архив работает намного медленнее, чем нынешнее сохранение файла данных. И это очень грустно, потому что мысли перейти на новый формат файла (xml+zip) уже появились, но пока неясно что делать со скоростью.
 
3. Насчет надежности сказать ничего не могу, по ощущениям, не должно быть менее надежно чем сейчас. К тому же, с учетом количества программ, хранящих данные в xml+zip, не думаю что будут какие-то проблемы. Если уж даже MS Office переходит на этот формат...
 
В общем, меня смущает только скорость обработки.
свернуть/развернуть ветвь Про новый формат [Дим(м) 08/07/2010 19:19] # написать ответ
 
Честно говоря, если говорить о выборе нового формата, то я бы, наверное, смотрел в сторону SQLite, а не "XML внутри ZIP".
 
Хотя, вообще странно, что так падает скорость. Я подозреваю, это, по большей части, из-за XML, а не ZIP. Если уж так хочется экономии места, можно попробовать сжимать/разжимать ZIP-ом теперешний формат.
Вообще, если говорить о контейнерах, то и шифрование стоило бы пересмотреть. Well
 
А насчёт надёжности я имел в виду, что теперешний файл ведь сохраняется по частям? Потому, например, и фрагментация возникает при удалении записей, как я понимаю.
А "XML внутри ZIP" каждый раз будет перезаписываться полностью. Соответственно, если что-то пошло не так, потеряются все данные, а не отдельные записи.
 
...скорости я погорячился. Сейчас трудновато сравнивать потому что DOM-дерево мне приходится строить заново перед экспортом. В реализации файла данных на DOM все объекты будут создаваться во время работы программы и, возможно, это несколько ускорит процесс. Кроме того, можно будет попробовать изменить степень сжатия zip, это тоже может оказать положительное влияние. В общем, пока не будем загадывать.
 
Если выбирать между SQLite и zip+xml, то мне больше нравится zip и вот почему:
 
1. Я пока не представляю как можно реализовать многоуровневый undo/redo на SQLite.
 
2. Сейчас весь код работает на контейнерах STL и если переводить на SQL, то переделки коснутся практически всего кода программы, переделывать придется все. Если же переключиться на ZIP+XML, то изменятся лишь алгоритмы чтения/записи данных.
 
В любом случае, я не думаю что смена формата, это задача, которой нужно заниматься сейчас.
 
А что делать человеку, который по полным сырым данным формирует себе тот отчёт который не предусмотрен и ни когда не будет предусмотрен? Всё время должен подставлять шаблон руками? Например суммарную калорийность купленных продуктов...