создать новую тему раскрыть все
Я бы предложил экпорт/импорт сделать при помощи XML файла - очень удобная вещь, в XML можно засунуть всё что угодно. И тогда можно будет использовать эти данные в других местах, например можно сделать укороченную версию для pocketpc...
 
Dervish: Ничего, что я перевёл Ваше сообщение с транслита на русский? Я сделал это буквально.
 
Наверное, но одно плохо: я совсем не знаю формата XML и никогда с ним не сталкивался. Ладно, формат наверняка описан в MSDN, но как им правильно пользоваться, для меня - тёмный лес.
Честно говоря, не понимаю серьезного преимущества XML по сравнению с текстовым файлом.
То, что там легче создавать древовидные записи с переменным количеством полей, конечно плюс, но это можно сделать и в обыкновенном текстовом файле.
И его "переносимость". Он не более переносим, чем тот же текстовой файл.
Преимущества следующие:
Во-первых, текстовый файл нужно парсить, а XML парсит готовая библиотека
Во-вторых, очень удобно при использовании древовидных описаний - скажем, агенты
Я уже больше двух лет использую только XML и скажу, что я очень доволен...
 
Dervish: Не нравятся мне дополнительные библиотеки. Обратите внимание, в Cash MFC не используется.
Действительно, для Windows уже есть готовая библиотека MSXMLParser (или как там его?). Действительно, в один файл очень органично можно загнать всю базу. Но!
Во-первых, скорость. Этот парсер дополнительно нагружает программу, когда самостоятельный парсинг csv-файла это даже не парсинг, так, баловство. Очень просто и быстро.
Во-вторых. На сколько увеличится программа?
В-третьих, совместимость. С какой версии IE он поставляется? Хорошо, если с 4-ой.
 
Первые два пункта -- самые важные.
 
Dervish: Ну вот, всё правильно, мне, если честно, больше нечего добавить.
По скорости разницы никакой и скорость в данном случае не нужна, мы говорим об экспорте/импорте
В системе он встроен, но есть возможность его проставить
И для чего заботиться о размере программы, по моему этот вопрос актуален только на PocketPC.
А парсинг CSV это тоже не такая и простая вещь, там тоже есть свои подводные камни.
 
Dervish: Как это, зачем не заботиться о размере? ИМХО, чем больше размер, тем больше кода; чем больше кода, тем программа медленнее работает... Плюс, лично меня временами даже просто необходимость закачать 2-3 мегабайта с интернета просто напрягает...
Никакой разницы в скорости??? Да ну... Скорость парсинга csv это преимущественно скорость чтения файла с диска, в остальном... Для XML это скорость чтения файла, разбор всех его деревьев и параметров, и общение через COM интерфейс. Тем более этот парсер от MS, значит ко всему этому можно прибавить еще 50% нагрузки. Скажу сразу, я не работал с этим парсером, но жалобы на скорость читал.
 
Так какие же подводные камни с csv??? Там, по-моему, проще некуда.
vezde gde ja ispolzoval xml, menja skorost` udovletvorjala.
sravnitel`nuje testy ja konechno ne delal, no mogu predpolozit` chto on mozet bit` medlenee csv skazem % na 20.
a na shet csv, problema bila v tom cho ty ne mozesh ispolzovat` razdelitelj vnutri predlozenija:
skazem u tebja razdelitel (,) togda ty ne mozesh v odno pole kinut` skazem (nalichnyje, v karmane) - eto budet kak dva raznih polja...
eshe excely nuzno chtoby bil opredelennij delimeter, a v raznih regionah etot delimeter raznuj, sootvetsvenno est` vetojatnost` cto esli ty fail csv sdelajesh skazem s finskimi regionalnumi settingami, to s russkimi ty etot fail excelem ne otkroesh
vrode eshe kakieto problemy bili s ", no shas ne pomnju
Забавно To wink)
 
Во-первых, значения полей, если внутри них есть разделители (напр. запятая) берутся в кавычки.
1, "Наличные, в кармане", 2
 
Во-вторых, проблем с " тоже нет. Если надо использовать " в поле, пишем "".
1, "Наличные, ""в"" кармане", 2
 
В-третьих, у Excel`я самого значения разделителей меняются от версии к версии. Так что... В Excel есть ручная настройка разбора csv, где самому можно указать какими символами пользоваться.
 
Ну да ладно, это так, к слову.
 
Насчет XML. Если использовать XML для импорта данных с PocketPC, то этот формат подходит как нельзя лучше, ИМХО. Хотя нет. Можно использовать и родной формат. Но тут у XML есть свои преимущества.
Вообщем, я не имею ничего против (я даже за , когда речь идет об импорте с PocketPC). Только csv не настолько плох, как Вы его описали To wink))
А вообще, против XML я ничего не имею. Довольно проятный и удобный формат, но не панацея, как все его почему-то называют.
Если задача требует его применения, пожалуйста, только за. Но если применение его не обязательно, то стоит подумать, использовать XML или обойтись другими средствами.
По поводу транслита сожалею, но у меня ноутбук без русских букв, живу я тоже за границей...
 
По поводу XML-a, я сам программист, и с удовольствием помог бы ответить на вопросы по этомцу поводу.
 
Dervish: Вы не поверите: у меня тоже ноутбук и тоже без русских букв! Well
 
Мне интересно вот какая вещь: как именно XML может помочь общаться с PocketPC? У меня есть Cassiopeia, есть пакеты для программирования для неё, но, честно говоря я нигде в доках не видел, как именно она работает с XML.
 
И ещё один вопрос по PalmPC. Не приходилось ли Вам сталкиваться с написанием Active Channels for desktop под PalmPC?
XML я предлагал для импорта/экспорта.
XML поддержан по WinCE
Отсюда: я делаю всякие программки под CE, и планирую написать укороченный вариант программы, где можно было бы использовать счета, расходы, ... из программы cash.
Укороченная версия - это версия где можно вносить расходы/приходы, но без анализа и всех наворотов. А потом всё что было введено на pocket pc, через тот же импорт/экспорт внести в cash - а ля синхронизовать.
 
Dervish: Замечательно. А не лучше ли будет сделать полноценную синхронизацию, встроенную в ActiveSync?
 
Вы ничего не сказали про каналы для Active Desktop (см. предыдущий пост).
Ja s palmami ne znakom, poetomu nichem k sozeleniju pomoch ne mogu. Ja sprosil pary znakomyh kotorije bolee znakomy s etim, no oni toze s etim ne stalkivalis`
Сергей, в XML ничего особенного нет, если рассматривать формат как таковой. Наверняка вы знакомы с HTML, а HTML является подмножеством XML.
 
Другое дело - интерфейс к парсеру XML. В разных системах программирования - разные парсеры, разные объекты/синтаксис и т.п.
 
Сам по себе формат НИЧЕГО не решает. Он не имеет никаких преимуществ перед CSV, если система (чужая) не знает, как интерпретировать структуру XML.
 
Пользоваться XML как хранилищем данных в пределах одной программы очень неэффективно. Необходимость в нем реально может возникнуть только при обмене данными с другими системами.
 
Dervish: CSV мне не нравится только одним: в нём приходится изворачиваться, чтоб представить иерархическую структуру. Я верно понимаю, что в XML такой проблемы нет? Но понятно одно, что если и делать поддержку этого языка, то библиотеками я пользоваться не буду, сам сделаю парсер для него.
"В разных системах программирования - разные парсеры, разные объекты/синтаксис и т.п."
Eto kaketo ? XML eto standart, bibliotekoi polzujeshja cherez COM interfacy (bud` eto na C++ ili Basic, ili eshe cto - odin hren ispolovanije odinakovo)
I ja KETEGARICHESHI ne sovetuju delat` svoij parser - eto bolshaja oshibka:
eto zajmet kuchu vremeni, togda kak cherez COM interfacy eto reshaetsja na porjadok bistree.
Prichem eto budet rabotat` i na WinCE
Я говорю о том, что есть разные библиотеки-парсеры, а не об использовании ОДНОЙ библиотеки из разных языков.
 
MSXML - одна библиотека, в MS SQL 2000 - другая, в Oracle 9 - третья, на PHP - четвертая, на Perl - пятая и т.д.
 
Вы же не станете утверждать, что у всех этих парсеров одинаковые названия и параметры функций?
 
Сергей, я согласен с тем, что НЕЛЬЗЯ пытаться писать свой парсер, только время зря потеряете. MSXML 4 - замечательный, быстрый парсер с кучей возможностей. И совершенно бесплатный для разработчика и пользователей.
 
Dervish: Насчёт написать собственный парсер, это я конечно же погорячился. Скорее всего, я просто не буду делать поддержку XML, поскольку не вижу, в чём именно это сможет помочь пользователю. Для экпорта/импорта ИМХО вполне достаточно текстовых (и/или CSV) файлов.
Поддержка же PocketPC мне представляется очень и очень желательной, правда, стандартными средствами синхронизации. Это возможно, я уже знаком с механизамами работы ActiveSync и написанием драйверов (библиотек) для этой синхронизации.
Dervish, возможно, вы уже изучили проблему, но если нет, то вкратце об XML:
1. Самый краткий вариант: XML - это группы из открывающих и закрывающих тегов.
2. Отсюда - http://www.gribuser.ru/xml/fictionbook/xml_what_is_it2.0.html
 
И чуть подлинее - XML в 10 тезисах - http://www.raleigh.ru/XML/2001/10points.php , там, кстати, о плюсах последний пункт.
 
В общем, это просто базовый формат, чтобы "договориться". По большому счету - о формате раздута большая шумиха, написаны мегатонные парсеры, которые по дефолту стоят не везде.
 
Лично я думаю, любой программист сможет распрасить CSV стандартными средствами.
...я знаю что такое XML.
 
Мало того, часть исходников у меня сделано в XML и транслируется в С++ при помощи XSLT.
0) Преимущества XML в основном связаны именно с обменом данными со сторонними программами. Но ведь импорт/экспорт предназначен, в том числе, и для этого?
1) Преимущество номер раз - стандартизованный механизм описания и, что очень важно, верификации структуры данных. Обращаю внимание - не сруктуры ФАЙЛА, содержащего данные, а структуры ДАННЫХ. Что сие означает:
- если у меня есть некий .csv (.xls, .dbf и т.д.) файл, я (программа Well) могу проверить, что это действительно файл соответвующего типа. Это несложно. Файл содержит только байты из диапазона 32-255, разделители строк cr/lf, в каждой строке есть по 18 запятых - да, это csv. Валидны ли данные в этом csv? ХЗ. Надо писать программу-верификатор, которая будет а) парсить формат и б) содержать hardcoded схему проверки данных. Типа: после восьмой запятой в строке должна быть дата, вернее, не дата, а последовательность символов "две цифры, точка, две цифры, точка, четыре цифры, при этом первые две цифры могут быть от 01 до 28, 29, 30, 31 в зависимости от..." Откуда эту схему взять? Как быть уверенным, что мой (той программы, которую я использую) парсер правильно проведет все проверки? Что делать, если она изменится в новой версии программы-источника данных? Переписывать свой верификатор?
- если у меня есть некий XML файл и дефинишн или схема, описывающие данные, ЛЮБОЙ парсер (хоть MSSQL, хоть явовский, хоть оракловский, хоть из php, хоть из линукса etc) может ответить на два вопроса - это действительно xml-файл и содержит ли он данные, точно соответвующие схеме, и если нет, то где ошибки и в чем они (типа, неверный формат даты, строка вместо целого числа, неизвестная сущность там, где должно быть описание объекта "проводка").
Соответвенно, имея схему, легко организовать экспорт данных из сторонней программы в формат, этой схеме соответвующий. Намного легче, чем в csv или xls. Ну захочется мне заполнять данные об операциях в InfoPath, экспортировать их из Navision, из какой-нибудь БД, или сделать web-интерфейс для ввода данных на моем сайтике через мобильник в wapv последующим импортом в конце недели в Cash - это легко будет сделать, если Cash примет на вход xml-файл, и схема для этого файла известна. И если она (схема) изменится - переделать механизм экспорта тоже будет не сложно.
2) Преимущество номер два - стандартизованный механизм преобразования xml-файла во что-то другое. Трансформ и стайл-шит - легко пишутся. Это не программы, это описания преобразования/форматирования. Потом любой процессор (опять таки, хоть MSSQL, хоть явовский, хоть оракловский, хоть из php, хоть из линукса etc) автоматически преобразует любой файл, соответвующий данной схеме в html, csv, pdf и т.д. Либо в xml другой структуры. И, наоборот xml другой структуры в данную, понимаемую Cash. Зачем? Масса применений. Сколько бы Вы не добавляли форм отчетов и графиков в программу, всех возможных вариаций все равно не охватить. Всю возможную аналитику не прикрутить.
3) Преимущество номер три - стандартизованный механизм запросов к данным. Вот есть у вас csv с данными из программы. Назовите средство, имеющееся в наличии на наладоннике, которое позволяет выбрать все данные, для которых число в третьем поле не более чем в два раза меньше числа в седьмом, и отосртировать результаты по восьмому полю asc, потом по одинадцатому desc? Для xml есть стандартный язык запросов, понимаемый, опять таки любым процессором (... см. выше Well).
 
Dervish: Аргументация ясна и понятна. Я подумаю, что можно будет сделать во второй версии. И огромное спасибо за то время, которое вы уделили этому сообщению.
Юрий, мне тоже все понятно, но пока я вижу, что автор занят более первостепенными задачами: реализацией новых и совершенствованием старых функций. Это нужно всем пользователям. Гипотетичекое применение XML, утяжеляющее программу и уводящее в сторону - это уже наворачивание огорода. Ясно, что на этом можно сделать утилиты и доп-программы, но вот мне например, простому учитывальщику домашниго бюджета по уши хватит 2й версии программы.
Единственное видимое применение - это наладонник, но, учитывая, что там вообще надо только два момента реализовать:
- закидывание скелета (счетов, агентов) в наладонник
- получение из наладонника операций,
ради этого париться с XML - чересчур муторно. Да, можно заюзать библиотеку, однако, вижу, у автора несколько иной стиль программирования. И хорошо, т. к. компоненты Дельфей да НЕТов все научились склеивать (и я тоже, кстати), а вот как автор попробуйте-ка.
 
P. S. Гистлер до сих пор пишет Тотал Командер в Дельфи 2 и переходить на высшие версии не собирается. В итоге мы имеем звездный продукт.
эта хрень не установлена в моем win 2000 prof RUS, где ее взять, чтобы доустановить, заранее сенкс
 
Dervish: Наверное она должна быть на сайте Microsoft. Хочу обратить ваше внимание, что в Cash пока нет импорта/экспорта в XML и, честно говоря, пока не планируется.
Не согласились бы вы опубликовать формат базы? Может кто-то захочет написать конвертер?
...это не благоприятно скажется на взломостойкости базы.
 
Повторюсь, я могу сделать экспорт в XML. Вот чего мне не хотелось бы делать (ввиду трудоёмкости), так это импорт из XML.
Строго говоря, взломостойкость базы без шифрации при незашифрованном коде программы весьма сомнительна.
 
Лично мне было бы достаточно выставить шифрацию файла базы на NTFS.
 
Что касается XML, то хотябы даже экспорт черезвычайно желателен.
.
Мне например именно экспорт и не нужен (пока).
А вот без импорта пользоваться программкой не очень-то получается.
Зачем забивать свои траты руками, когда тебе банк и так предоставляет все твои транзакции?
Вид предоставления в данном случае вторичен.
Начал использовать AbilityCash (210) - понравилось. Спасибо.
Но все-таки хотелось бы вытащить свои данные в виде xml.
 
IMHO, нет смысла экспортировать данные СРАЗУ в формате OpenOffice. Задача должна быть разбита на два этапа:
1) Экспорт данных в xml-структуру <B>наиболее целостную и непротиворечивую</B> с текущей структурой внутренней базы AbilityCash (я имею в виду наличие различных "классификаторов" и операций классифицированных по ним). То есть это должно быть как-бы XML-представление тех струтур, которые вы используете для для работы самой AbilityCash. =) Теоретически можно попытаться воспользоваться каким нибудь xml-сериализатором, но не знаю как с этим делом обстоит у сишников =( есть ли такие библиотеки вообще.
 
2) Трансформация (XSLT) в формат OpenOffice.
 
BTW, полученная на выходе целостная xml-структура может быть использована и для генерации отчетов...
 
P.S. Решение второй задачи могу взять на себя. Будут вопросы - пишите.
...XML - наиболее вероятный кандидат на экспорт (и импорт). После Экселя, уже реализованного.
 
У Си-шников дело с XML обстоит неплохо: можно пользовать DOM, можно одну из огромного количества частных библиотек. В конце концов, можно ручками текстовый файл записать.
 
Проблема как раз не в экспорте. Проблема в импорте. Очень нудная обработка (возможных) ошибок и сообщения о них. а делать экспорт без соответствующего импорта, не уверен, что это будет хорошо.
(XSD, Schematron или RELAX NG) для проверки на валидность импортируемого файла. Как я уже объяснял, структура импортируемого xml-файла должна быть как можно более близкой к внутренней стуктуре используемой внутри программы.
Это конечно хорошо, делать и экспорт и импорт одновременно, по я думаю что имеет смысл идти маленькими шашками. Давайте для начала сделаем экспорт.
маленькими шашками
ну раз вы так настаиваете.. =)