Сохранить проект без ZIPa?

Добрый день!
Просьба к программистам Owen Logic.
Добавьте возможность сохранения проекта без упаковки в ZIP. Как обычный текстовый файл.
Вы ведь знаете что такое GIT, пользуетесь им и вам это нравится. Зачем лишать пользователей вашего приложения возможности использования подобных средств?
Я думаю, что здесь достаточно людей, для которых JSON и GIT не просто страшные наборы букв.
Да, сохранение JSON в текстовом файле без упаковки значительно увеличит размер файла, но зато появится возможность нормальной работы с GIT.
Возможность делится проектами и работать совместно. Не мне вам рассказывать об инструментах, облегчающих жизнь программиста.

А Вам прямо не удобно писать проекты малой автоматизации без этих фишек?

Хах!! Ща будет совпадение и асбест (в два-три слоя) на стул. У меня подгорает от проектов OwenLogic, потому что я в них порылся (очень поверхностно).
Далее будет идти то, от чего у меня подгорело (раз асбест понадобилось на стул подкладывать). Всё в виде размышлений и без доказательной базы.
Всё будет рассчитано на программистов, знакомых с ООП и методами типа Serialise/Deserialise и с форматами файлов.

Все проекты и макросы OWL содержат в себе кучу-кучу таких строк:
* SNevron.Diagram, Version=9.11.3.12, Culture=neutral, PublicKeyToken
* Nevron.Diagram.Extensions.NPersistentDocument
* Nevron.Diagram.Extensions.NPersistentSectionCollec tion
Это давно наводило меня на мысль о том, что что-то тут не чисто, и что файл слишком мутный по его формату.
Прям вот недавно мы с Bayk это всё обсуждали и, увидев эту тему, я пошёл рыть. Вот что нарыл: https://www.nevron.com/products-dot-...agram-overview
Собственно всё рисование в OwenLogic построено на этом движке диаграмм. И сохранение проекта выполняется его функциями.

И вот тут у меня наступает шок и дикая ненависть в сторону разврата, к которому приводит .NET. Это касается и каких-нить конструкций типа
Result = MyVar.toNumber.Math.Mul(10).toString.indexOf(-2).ConCat("Value").toHEX.SaveToFile(); //Да здравствует ООП, мать его
И того, что судя по такому мракокоду люди отвыкли думать головой и привыкли идти по самому лёгкому пути, используя готовые компоненты.
Короче. OwenLogic сохраняет не описание объектов и их связей, а прям саму СХЕМУ КАК ЕСТЬ. Поэтому и файлы проектов такие жирные получаются.

Если можно выдумать гротескную аналогию, то я бы выдумал, образно так, на примере финансов: вместо записи в базе данных типа "+50 000.00 на счёт" (в переменной типа REAL/FLOAT) сохранять скриншот платёжки в BMP и сжимать его ZIP. Вот как хранит проекты и макросы Owen Logic!!

У меня дико подгорает от того, что файл проекта ВСЕГДА зависит от версии Owen Logic! Вот на форуме кто-то сохранил проект в условной версии 1.7.9.21 - и всё, приплыли! Даже если у тебя версия 1.7.9.20 - похер, ничего не откроется!!
Из-за чего? А из-за того, что версия Nevron Diagram, скорее всего, привязана к формату файла. И когда она меняется - то и файл хрен откроешь.

А что надо было сделать (сразу, а не "потом")? Надо было сделать свой формат файла проекта, который не зависит от версии Nevron Diagram и имеет обратную совместимость. Я своих разработках использую следующий приём:
0) Файл начинается с заголовка, в котором прописана версия его формата и другие данные.
а) Данные хранятся в виде последовательности структур (struct), где находятся все числовые данные и указаны длины строковых данных.
б) Строковые данные хранятся после структур побайтно
в) Каждая структура начинается с поля-заголовка (число DWORD, 4 байта - чтобы можно было глядеть в HEX с распознавать начало и конец данных, восстанавливая битый файл) и поля-версии структуры (число DWORD, 4 байта).
г) В зависимости от считанной версии структуры её данные интерпретируются по разному.
Например, в версии 1.0 в структуре может быть 10 полей, и её размер в байтах будет 36.
А в версии 1.1 в структуре будет 25 полей, и размер в байтах будет уже 126.
Зная версию структуры мы знаем, сколько байт читать и как их интерпретировать. И имеем обратную совместимость (новые поля ставятся в значения по умолчанию, а пользователю выдаётся предупреждение, мол "Вы загрузили файл старого формата, проверьте такие-то свойства объектов").
Никто не мешает заменить структуру каким-нить JSON (с тем же полем версии) или ещё чем-то.

А хранить надо было не всю диаграмму (нахера рисунок-то хранить), а объекты и их свойста. Буквально, образно так (в бинарном или текстовом формате):
* Объект: ID = 1, Тип = TON, Имя = TON1, Комментарий = Выдержка включения, ПозицияХ = 200, ПозицияY = 320
* Объект: ID = 2, Тип = DO, Имя = DO1, Комментарий = Выходной сигнал, ПозицияХ = 10, ПозицияY = 500
* Соединение: Начало = ID1.Q, Конец = ID2.Q, ТочкиЛинииXY = (205, 350), (15, 400), (15, 490)

А при загрузке проекта потом уже рисовать по ним диаграмму на лету. Так делает P-CAD (Altium Designer), CodeSys, Logo, Eaton. Никто не сохранет, образно, скриншот всей схемы!!!
Плюс такого формата в том, что объекты запоминались бы по имени их типа, а не по их рисунку. Так же можно было бы легко перемещать входы-выходы макросов (потому что сохранялся был не рисунок макроса, а его описание) в нужном порядке, дополнять их нужными свойствами (которые на экране можно даже не отрисовывать, чтобы они сохранились)...

И это не зависело бы от версии среды разработки. Версия формата менялась бы только при серьёзных случаях. Например, если разработчики решили добавить свойство "Цвет" для всех-всех объектов и под него потребовалось бы новое поле в файле. Но и то данные были бы обратно совместимы:
* в проекте старого формата при загрузке в новую среду Цвет встал бы на значение по умолчанию
* в в старой среде при загрузке нового проекта можно было бы игнорировать это свойство, предупредив пользователя "...проект был сохранён в новой версии среды, некоторые функции будут недоступны".

Короче, я ОЧЕНЬ ЗЛИЩЕНСКИ ЗОЛ. В основном на менталитет "Сначала сделали, потом подумали, а не наоборот".

Попробуйте в КДС3 открыть проект в более старой версии.

Cs-Cs я писал раньше, делая версию 2.х нужен был другой подход, в пример приводил xml файл от ПЛК Beckhoff, который в РАЗЫ занимает меньше места.

имхо, надо было использовать КООРДИНАТЫ для FBD в файле проекта.
И еще такой момент, делая драйвер для облака разбирался с json (меня там тыкали носом что за json будущее) но я так и не нашел способа не записывать при сериализации пустые элементы, что легко делается в xml еще больше сокращая файл.

Например если булевая переменная false, или int переменная = 0 то в выходном файле xml просто не будет записей Булевая 1 = "false"

з.ы. и кстати при использовании xml в структуры легко можно добавлять новые данные для новых версий ПО и старые вресии будет легко открывать проекты, так как происходит игнор неизвестных данных.
Полезно при добавлении новых приборов.

ASo Ага, я понял, о чём ты: он будет ругаться, говорить что не найдены таргеты, но загрузит что-то всё равно. Я так делаю иногда, чтобы в старом 3.5.SP5 на WinXP открыть проект от 3.5.SP14 и оттуда код скопировать.

melkiy Ухты! Почти впервые вижу понимание. Жму лапу!

Цитата:

---

имхо, надо было использовать КООРДИНАТЫ для FBD в файле проекта

---

Да, я про это же и говорил. Хранить инфу в виде "Штуковина такого-то типа (TON, TOF, AND, Макрос) по таким-то координатам с такими-то соединениями".

Так западло сериализации как раз в том, что она самая топорная и стандартная. Поэтому если ты взял класс JSON и сказал ему сериализоваться - то он и запишет все значения. И единственный путь - это генерировать JSON самому на лету.
А XML, кстати, круто упаковывается в тот же ZIP. И как раз для систем контроля версий подойдёт.
Можно в Owen Logic сделать аналогию с CodeSys в виде трёх режимов хранения проекта (с разными степенями защиты): голый XML без ZIP, XML в ZIP, XML в ZIP с паролем.
И ещё как раз подойдёт для случаев, когда проект повредился в хлам, и из файла надо достать хоть кусок данных. И это будет очень мощное и конкурентное преимущество Owen Logic перед другими средами разработки.
Или если надо... написать программу, которая делает программы: она будет генерить XML-проект для Owen Logic на лету, например.

Короче, ВОТ. Теперь нам с тобой нужна премия. А ОВЕНу - пинок.

Если бы это было так.
Банально не открывает.

Cs-Cs нет, тут подход в сериализации. Она основана на создании классов, JSON не умеет игнорировать пустые поля или имеющие стандартно определенные значения типа false или 0
Не все xml сериализаторы это так же умеют, но один старый добрый xml serailiser сволочь так умеет :)

Овен пинать бесполезно, мне было сказано буквально следующее - XML устарел, JSON наше все... ну вот и ВСЁ :)
а еще меня веселит множитель, он бббб с 8-ью знаками после запятой.

а 1 это один байт, а вот 1.00000000 что то же самое, что и 1, ну по крайней мере не хуже, занимает на ДЕВЯТЬ байт больше. и так по всему json проекта прогуляться, становится страшно :)

Хотелось увидеть комментарий разработчиков, но видимо их сюда не пускают:(