до коих пор, я вас спрашиваю, адни будут за других пахать? хотя в самой теме было ясно, что предлагаеца камунить навоять гатовое решение
пройдитесь хотя б по-диагонали топика: афтару ни раз намекали-говорили об ущербности в нестандартном подходе, ан нетушки - дайте мне гатовое решение
как вариант мона было б и не заморачиваться со всякими там форматами, а клепать обычные дбфники, 1це их кушает без проблем, а фокс так тем паче

Спасибо всем ответившим.
Просьба не флудить, просьба про достоинства и недостатки XML, TXT и прочих форматов не писать, тема о другом.

Собственно, вопрос решен, все уже работает.

Я просил дополнений, что еще можно экспортировать в txt файл,
помимо перечисленного мной во вложении в первом посте,
то есть какие еще характеристики (из Вашей практики) может иметь ассортимент продукции.
ГЛАВНАЯ ИДЕЯ: При экспорте выводится как можно больше информации (не обязательно),
при импорте только то, что используется в программе.

ssa - спасибо за пример использования XMLAdapter
В данном случае он не подходит и дает ошибочные результаты
(Формат таблиц как видите простой, но обработка в программе довольно сложная,
пять уровней вложенности разделов, "объяснить" это XMLAdapter очень трудно),
да и имена тегов - это имена полей таблицы, что недопустимо.

Это я уже проходил, ни с кем не хочу спорить, мне в данном случае лучше и проще txt

Буду сам дорабатывать, если кому интересен результат, пишите в личку.

А что касается гатовых решений от Foxtrot,
то программа уже давно работает и пользователи довольны.



Исправлено 1 раз(а). Последнее : Asws, 10.02.09 20:33

Asws
ssa - спасибо за пример использования XMLAdapter
В данном случае он не подходит и дает ошибочные результаты

Какие? Где? Коенкретнее можно?

Цитата:

(Формат таблиц как видите простой, но обработка в программе довольно сложная,

О какой обработке идет речь? В моем примере взяты Ваши данные. Обработанные.

Цитата:

пять уровней вложенности разделов, "объяснить" это XMLAdapter очень трудно),

Да ему по барабану. Откуда вывод о сложностях объяснения адаптеру?

Цитата:

да и имена тегов - это имена полей таблицы, что недопустимо.

Почему недопустимо? И что мешает все именовать так, как надо? Незнание того, как это делать? Покажем.

Цитата:

Это я уже проходил, ни с кем не хочу спорить, мне в данном случае лучше и проще txt

Что ЭТО? О чем речь? А то я что-то не вкурил.

Цитата:

Буду сам дорабатывать, если кому интересен результат, пишите в личку.

Как обычно...

Цитата:

А что касается гатовых решений от Foxtrot,
то программа уже давно работает и пользователи довольны.

Железный аргумент.

Цитата:

Какие? Где? Коенкретнее можно?

Получившийся XML файл содержит неверное распределение продукции по разделам,
нет уровней вложенности разделов. Далее не стал даже копаться.

Цитата:

О какой обработке идет речь? В моем примере взяты Ваши данные. Обработанные.

Импортированные, обработка происходит динамически во время вывода списка продукции, ListBox + Grid

Цитата:

Да ему по барабану. Откуда вывод о сложностях объяснения адаптеру?

Вот видишь, "в лоб" это не решается, пример не дает экспорт правильных данных.

Цитата:

Почему недопустимо? И что мешает все именовать так, как надо? Незнание того, как это делать? Покажем.

С удовольствием посмотрел-бы, но занимать время профи не хочу, потому что подозреваю, что все буду делать по своему...

Цитата:

Что ЭТО? О чем речь? А то я что-то не вкурил.

Да все просто, не умею я готовить XML

Цитата:

Как обычно...

А как мне поступать, если на конкретный вопрос и предварительный формат ТЗ
мне начали объяснять, что мне надо использовать, а что нет, и дошло до хамства?

Даже комментировать не хочется.
Удачи в изобретении очередного велосипеда.

Должно быть где-то так:
(dbf,txt,xml,xsd - файлы во вложении)

Ничего не понял. Каким образом содержимое imp.zip соотносится с SP.dbf и sr.dbf?

Вообщето для 1С былобы проще всего иметь DBF
самому приходится заниматься переливанием информации

Извините, много дней не был на форуме. (об этом тема в Курилке).
ssa, это я затупил, сбили меня с первоначального вопроса
SP и SR - это в данном приложении - внутренний формат, а между приложениями
нужен экспорт/импорт, в этом главный вопрос темы.
Принципиально не важно КАК, главное, ЧТО передавать между приложениями.
Здесь при передачи с помощью XML или DBF все-таки присутствуют имена полей
( которые тоже можно задать постоянными в рекомендуемом (унифицированном) формате ).
IMXO при использовании TXT получается самый чистый формат, без имен тегов и полей.

Asws
Извините, много дней не был на форуме. (об этом тема в Курилке).
ssa, это я затупил, сбили меня с первоначального вопроса
SP и SR - это в данном приложении - внутренний формат, а между приложениями
нужен экспорт/импорт, в этом главный вопрос темы.
Принципиально не важно КАК, главное, ЧТО передавать между приложениями.
Здесь при передачи с помощью XML или DBF все-таки присутствуют имена полей
( которые тоже можно задать постоянными в рекомендуемом (унифицированном) формате ).
IMXO при использовании TXT получается самый чистый формат, без имен тегов и полей.

Не получается. Точнее, вы переносите вопрос идентификации "полей" на уровень кода. Все метаданные прописаны вне файла TXT.

Собственно, об этом и идет спор. Информацию мало передать, ее надо передать внятно. Понятно для принимающей стороны.

Давайте на простом примере.

Надо передать некий номер и количество. Это можно передать так:

123 456

Что здесь "номер", а что "количество"? Разумеется, можно "договорится", что сначала стоит номер, а потом количество. Т.е. и передающая и принимающая сторона должны иметь очень жестко прописанный формат того КАК передается информация.

Обращаю внимание на то, что принципиально важным, просто жизненно необходимым, становится вопрос не ЧТО, а именно КАК.

Теперь, предположим, ту же самую информацию передают вот так:

Номер=123 Количество=456

Вопрос идентификации информации уже не стоит. Вопрос "КАК" отпадает за ненадобностью. И вот только теперь можно уделить самое пристальное внимание тому ЧТО передается.

Другими словами, использование "голого" TXT создает дополнительные проблемы по стандартизации того КАК передавать информацию. В то время как XML или DBF этой проблемы не имеют.

Спасибо Владимир.
КАК очень важно. В этом-то и проблема.
В процессе импорта идет преобразование в свой формат из промежуточного, который я и хотел
с помощью Уважаемых коллег привести к общепринятому стандарту, если это возможно.

В любом случае приложение, импортирующее данные должно опираться или на жесткий формат,
или на жесткие ограничения по НАИМЕНОВАНИЮ полей данных ("Номер", "Количество"),
чтобы ПРАВИЛЬНО импортировать данные.

Представьте такую ситуацию :
Получен XML - файл, он прекрасно преобразуется в таблицу(ы) с данными, а потом что с ним делать?
Ведь это промежуточный формат, который должен содержать как можно больше данных.
Что приложение должно делать? Использовать синтаксический анализатор наименований полей?
Потому что приложение может импортировать не все поля, а только те, что использует.

В первом посте этой темы я приложил файл с форматом передаваемых данных
( этот формат в данном случае проще показать в txt формате, включив в него как можно больше информации )
Вот об этом и тема. Это касается не только FoxPro, а любого приложения любой ОС.



Исправлено 1 раз(а). Последнее : Asws, 23.02.09 11:26

Привет Александр!

Жёсткий формат несомненно более "жёсток" нежели жёсткие наименования полей.
Из XML совершенно не обязательно забирать ВСЮ информацию - ты просто указываешь какие "поля" тебя интересуют и всё!
Более того, если тебе надо в результате получить файл другой структуры (банально - с другими "именами полей", или объединив часть полей в одно, или преобразовав "несколько таблиц" хранимых в XML файле обособленно в одну "широкую и плоскую" таблицу) - то это можно сделать непосредственно из XML файла с помощью сравнительно несложного преобразования. Из формата txt это сделать невозможно в принципе.

Поэтому тебе и советуют вместо изобретения велосипеда в области "физического" уровня представления, сосредоточится на более высоком "логическом" уровне - т.е. определить какие нужны поля (их типы и ограничения на них накладываемые), какие нужны дополнительные справочники, их стурктуры, какого рода иерархия нужна и как её оптимальнее хранить - отдельно от собственно "классифицируемых сущностей" или сразу вместе с ними...
Тут уместна такая аналогия - когда ты программу проектируешь, ты просто используешь например dbf формат, не задумываясь сильно как оно там физически организовано - т.е. не изобретаешь заново структуру табличных файлов, индексов, способ хранения дат, вещественных чисел и т.п. Так вот XML даёт тебе ровно те же самые возможности (причём кроссплатформенно) - забыть о "физике" и сосредоточится на "логике".

Как говорилось в одном известном мультике - "лучше день потерять, а потом за пять минут долететь" (c) Так что потрать некоторое время на изучение технологии - это обязательно даст большой выигрыш в дальнейшем.

Понимаете, вы принципиально не правильно сформулировали саму задачу. Как это не покажется странным, вопрос ЧТО передавать - не важен, поскольку не может быть стандартизирован "по определению". Это решается для каждой конкретной задачи индивидуально.

Поэтому, на первое место выходит вопрос КАК передавать. Т.е. именно что формат этого самого промежуточного хранилища данных. Т.е. даже не отдельного файла, а набора файлов.

Так вот, при такой постановке задачи, "гладкий" текстовый файл имеет существенный недостаток перед XML. Именно в силу того, что его невозможно анализировать "как есть". Без дополнительного файла с описанием структуры.

Я открыл приложенный файл и что? Откуда я знаю, что это за буковки и циферки? Что они вообще обозначают? На что я смотрю? Что тут можно исправить, а что нельзя трогать? Я "повязан по рукам и ногам". Максимум, что я могу сделать это тупо пялится на эту "кашу" боясь что-то там случайно изменить!

С другой стороны, для XML-файлов файл схемы XSD - это всего-лишь "уточнение". Некие формальные правила разбора. Но файл XML можно "понять" и без схемы. Более того, схема - желательна, но вовсе не обязательная для передачи данных. Я в любой момент могу открыть файл XML и уже имею общее представление о том, что здесь вообще находится. Что можно менять, а что нельзя.

Asws
В любом случае приложение, импортирующее данные должно опираться или на жесткий формат, или на жесткие ограничения по НАИМЕНОВАНИЮ полей данных ("Номер", "Количество"), чтобы ПРАВИЛЬНО импортировать данные.

Когда вы работаете с файлами DBF или промышленными СУБД вроде MS SQL или Oracle вас ведь не смущает именно жесткий формат и жесточайшие ограничения по наименованию полей? Почему же это вас смущает при организации промежуточного хранилища данных?

Asws
Получен XML - файл, он прекрасно преобразуется в таблицу(ы) с данными, а потом что с ним делать? Ведь это промежуточный формат, который должен содержать как можно больше данных. Что приложение должно делать? Использовать синтаксический анализатор наименований полей?
Потому что приложение может импортировать не все поля, а только те, что использует.

А теперь вместо "XML-файл" вставьте в эту же цитату "TXT-файл". Лично я разницы не вижу. Придется делать все то же самое. Прочитать ВСЕ, а потом "выковыривать" нужное. Только для файла XML - это сделать проще, поскольку есть стандартные правила разбора. А для TXT эти правила придется придумывать самому.

Обращаю ваше внимание на еще одно ваше же требование: Файл должен быть легко понимаем и модифицируем при чтении простым текстовым редактором. Файл XML удовлетворяет этому требованию. А файл TXT в вашем формате - нет.

==========================================================================================================

В общем, проблема в следующем:

XML-файл - это стандарт. К нему есть описание, есть разные приемы и способы работы.
TXT-файл - стандарта НЕТ. Приемов и способов работы НЕТ. Все придется выдумывать самому.

А теперь докажите, что ваш самописный стандарт на базе TXT файлов лучше, чем уже существующий на базе XML.


Вопрос ведь не в том, какой именно формат вы придумали, а в том, почему вы не хотите использовать уже существующие способы организации промежуточного хранилища данных на базе XML или DBF? Какие у них есть недостатки? Даже не в сравнении с чем-либо, а просто что именно в них вас не устраивает из-за чего надо выдумывать что-то свое?

Спасибо, Вы меня убедили.
Название темы можно подправить : Унифицированный формат передачи данных.
Прошу поддержки (не для себя, а для всех) именно в общих соглашениях
по наименованию полей и их возможному количеству и содержанию.
Все форматы должны быть описаны с примерами (XML, DBF, TXT, и прочие)

Это нужно не только мне, одному такое не сделать, это не жизненно необходимо, но очень часто бывает нужно.
Может зантересованные Коллеги совместными усилиями и своим опытом помогут (не мне, а всем).

Об этом тема
(лично я все равно буду использовать TXT формат, но и XML тоже буду включать)