Вызывает интерес вот такой еще разрез

[Лекс Айрин]

Файлы не привел т.к. форум не дал в теги code вставить XML в кодировке UTF8. Перекодировать не проблема, но лень.

Вот честно, отмазки достойные нуба -- копипаст рулит в такого рода вещах. Да и есть куча способов передать файл.

[alexs]

И что из этого вина XML? Там нет экранирования?

ДА! Это недостатки стандарта! Было бы явно сказано - ТОЛЬКО UTF8 И НИЧЕГО БОЛЕЕ!!! вот тогда норм. А когда начинаются костыли с кодировкой в заголовке - это мрак. Т.е. ты должен сначала читать заголовок как последовательность 7-битных символов. Определяешь кодировку. А только после этого уже начинаешь читать текст в рамках этой кодировки. И как это назвать?

Или используй налоговая формат подобный lfm все было бы шоколадно?

Для нужд налоговой хватило бы старого доброго DBF.

Странный вопрос. Не использовали XSD? Это одна из сильнейших сторон XML, наряду с XSLT и XPath.

Т.е. вам это нужно только для построения интерфейсов без самого визуального редактора? А тогда зачем вообще вам нужен лазарь?
А если только для наложения изменений - то откройте для себя DIFF файлы. Быстрее и меньше размером

А что касается работающей технологии, то во-первых потрачено время на ее создание, во-вторых тратится на поддержку. Использовался бы XML, вместо поддержки lfm можно было более полезную вещь запилить - поддержку XSD, например.

Ещё раз - зачем это нужно графической среде разработке? Я руками рисую мышкой требуемый мне интерфейс. Зачем мне преобразования?
Может я чего-то не понимаю - научите...

[Mirage]

Т.е. ты должен сначала читать заголовок как последовательность 7-битных символов. Определяешь кодировку. А только после этого уже начинаешь читать текст в рамках этой кодировки. И как это назвать?

Полезная возможность. Если зафиксировать в стандарте utf-8 only, то это ж не помешает той же налоговой делать файлы в 1251.
И потом, можно же ее не использовать и считать все utf-8.

Для нужд налоговой хватило бы старого доброго DBF.

И я о том же. Если есть возможность использовать бинарный формат (фичи текстового не нужны), то так и надо делать.
Но если используется текстовый, то лучше какой-нибудь стандартный.
Тут кричат, что XML больше lfm в 100 раз (что чушь, т.к. в примерах тех же крикунов больше чем в 2 никак не получается) и вообще не красивый. Так есть же JSON.

Т.е. вам это нужно только для построения интерфейсов без самого визуального редактора?

Способность к валидации созданного и визуальному редактору пригодится.
К тому же формы таки иногда редактируются руками. А тут все пригодится.

А если только для наложения изменений - то откройте для себя DIFF файлы.

Это предложение не понял - причем тут DIFF?

Ещё раз - зачем это нужно графической среде разработке? Я руками рисую мышкой требуемый мне интерфейс. Зачем мне преобразования? Может я чего-то не понимаю - научите...

Вы спорите с тем, что ресурсы, потраченные на разработку и поддержку формата lfm можно было потратить на другие задачи, или с тем, что поддержка XSD в IDE в любом случае нужна? Как и JSON, кстати.
Первое очевидно.
Зачем нужна поддержка XSD среде разработки? Без умения работать с XSD говорить о поддержке XML смешно. Поддержка работы с XML файлами (не обязательно формами) среде разработки нужна потому что от XML никуда не спрячешься. Глядишь, с такой поддержкой и народ быстрей осознает, что лучше использовать стандартные инструменты, чем велосипеды.

[vitaly_l]

чушь, т.к. в примерах тех же крикунов больше чем в 2 никак не получается) и вообще не красивый.

при размере файла 500 Мб разница в 2 раза (о которой Вы говорите) - это 250 Мб... ах да пример - не красивый...
А если бы файл весил 100 Гб, то это 50 Гб? Да? <== Красивый? ==> XML <=== самый бесталанный велосипед за всю историю программирования...
И полно прекрасных форматов, которые можно привести к единой УДОБНОЙ структуре, которая справится с любой задачей 100% лучше XML.


.

[Mirage]

vitaly_l: Вас понесло какую-то чушь писать. Если немного подумать, прежде чем писать, то в 2 раза (по сравнению с lfm) это худший случай, когда кроме тегов больше ничего и нет. Да и форм таких не бывает, чтобы даже в 2 раза разница имела значения. Так что для форм XML объективно лучше lfm.
А так, я XML недолюбливаю, если что.

[скалогрыз]

Так что для форм XML объективно лучше lfm.

ну а как именно форму описать черех XML?

1) имя тега = имени свойства

Код: Выделить всё

<form>
  <left>100</left>
  <top>50</top>
</form>


2) парами ключ / значение?

Код: Выделить всё

<object>
  <type>form</type>
  <properties>
    <property><name>left</name><value>100</value></property>
    <property><name>top</name><value>50</value></property>
  </properties>
</object>


3) ещё как-то? (через аттрибуты)

[Лекс Айрин]

Mirage, не забывайте, что теги еще потом выкусывать надо... то есть, завершающие теги тут, в большинстве случаев лишние.

[Mirage]

скалогрыз: Мне вариант 1 больше нравится. Хотя тут думать надо.

Лекс Айрин: Зачем их выкусывать?

[Лекс Айрин]

Mirage, то есть, теги уйдут в результирующий файл? Не знаю как это у вас парсер для текстового файла получается сложнее, чем парсер XML... лично мне было бы проще (и намного) обработать текстовый lfm.
кстати, первый вариант почти один в один аналогичен обычному текстовому формату. Только занимает больше места.

[alexs]

Mirage
Я так и не увидел от вас ни одного ответа - какой явный профит принесёт замена LFM на XML. Ну кроме ответов, сводящихся к тому, что XML - это круто и модно.

Наверное останемся при своих мнениях

[скалогрыз]

1) имя тега = имени свойства

Код: Выделить всё

    <form>
      <left>100</left>
      <top>50</top>
    </form>


скалогрыз: Мне вариант 1 больше нравится. Хотя тут думать надо.

тогда XSD не прикрутить, т.к. весь набор свойств заранее неизвестен.

[Mirage]

Я так и не увидел от вас ни одного ответа - какой явный профит принесёт замена LFM на XML.

Попробуйте спросить у того, кто предлагал что-то заменять.
Если же речь о профите, который мог быть, если бы XML использовался изначально (так сказать, на будущее), то ответы были. Явных как минимум два. Читайте внимательнее.

тогда XSD не прикрутить, т.к. весь набор свойств заранее неизвестен.

Если искать причины, почему не прикрутить, всегда можно найти.
Если искать возможности, то тоже можно найти.
Например:

Код: Выделить всё

<form>
  <knownProperies>
[тут известные свойства, описанные в XSD]
  </knownProperies>
  <customProperies>
[тут остальные]
  </customProperies>
</form>


И, кстати, почему это набор свойств не известен? Лазарус же с ними работает. Значит можно XSD сгенерить динамически.

[Лекс Айрин]

И, кстати, почему это набор свойств не известен? Лазарус же с ними работает. Значит можно XSD сгенерить динамически.

Напоминает бег на костылях.

[скалогрыз]

Если искать причины, почему не прикрутить, всегда можно найти.
Если искать возможности, то тоже можно найти.
Например:

Код: Выделить всё

    <form>
      <knownProperies>
    [тут известные свойства, описанные в XSD]
      </knownProperies>
      <customProperies>
    [тут остальные]
      </customProperies>
    </form>


Отличный пример, потому что он как раз соответствует ранее приведённому варианту №2, осталось только нужно описать тэг <property>

И, кстати, почему это набор свойств не известен? Лазарус же с ними работает. Значит можно XSD сгенерить динамически.

Объясняю почему вариант №1 (имя свойств=имя тэга) и XSD будет непрактичным.
Набор свойств может менятся в течении разработки. Например, при создании собственных компонентов, свойства можно публиковать, переименовывать и т.д.
Пересборка/перепроверка XSD совершенно теряет смысл, потому что её точно так же нужно будет пересобирать после каждой компиляции проекта.
Ну и конечно об универсальной XSD для любого возможного проекта речи быть не может, т.к. этих самых компонентов тысячи, помноженное на десятки различных свойств.

В конце-концов, XSD был придуман, для тех случаев, когда есть множество независимых источников XML файла. И чтобы все они слали правильно сформированный XML, они все могут сверяться с одним общим XSD. А в Лазарусе сам себе и источник и обработчик данных.

[Mirage]

Отличный пример, потому что он как раз соответствует ранее приведённому варианту №2

Не соответствует. В варианте №2 названия свойств предполагаются в качестве значений тега <name>. В данном же примере, названия свойств соответствуют названию тегов, как в варианте №1. Собсно, отличие от варианта №1 только в том, что разделены известные свойства и неизвестные. Чтобы валидировать известные с помощью схемы. Хотя возможные значения тоже можно описать в схеме, так что и вариант №2 можно валидировать. Но он какой-то громоздкий.

Пересборка/перепроверка XSD совершенно теряет смысл, потому что её точно так же нужно будет пересобирать после каждой компиляции проекта.

Пересборка XSD после изменения набора компонент в Лазарусе (сейчас это возможно только при его перекомпиляции) как раз имеет смысл. Потому как только в этом случае меняется набор допустимых свойств в форме.
Если я просто добавлю пару свойств своему компоненту, но не установлю новую версию в Лазарус, то он ведь не позволит мне использовать новые свойства при дизайне формы?
Так что зачем менять схему после компиляции проекта?

Ну и конечно об универсальной XSD для любого возможного проекта речи быть не может, т.к. этих самых компонентов тысячи, помноженное на десятки различных свойств.

Тут конечно сперва стоило бы уточнить зачем нам XSD. Если чтобы валидировать форму при конкретном установленном наборе компонент, то генерация XSD - самое то. И кстати, ввиду формальности XSD, это не сложно. Набор свойств, а для многих и допустимые значения, Лазарус уже имеет.
Что есть "универсальной XSD для любого возможного проекта" и зачем, не очень понимаю.

В конце-концов, XSD был придуман, для тех случаев, когда есть множество независимых источников XML файла.

XSD используется в случаях, когда есть некий формат, а также задача валидации данных на соответствие этому формату.
В случае форм как раз есть их формат и данные, создаваемые дизайнером форм, либо пользователем. И то и другое полезно валидировать.

Плюсом к валидации формальность описания, готовые парсеры/сериализаторы и понятность формата сторонним разработчикам.