САПР на Lazarus

[vitaly_l]

А могу и не извлекать..

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

object
   img=png:base64:...
   img=png:base64:...
   img=jpg:base64:...
   img=tiff:base64:...
   src=http://..
   zip=base64:..
end;


Всё одно и тоже. Точно также можно извлекать или не извлекать.
XML - примитивный громоздкий формат, который легко заменяется нормальным. Просто те кто создавал XML - не умели думать и содрали всё с другого формата, а остальные подхватили "мол круто", а на самом деле ГРОМОЗДКО!!!

[zub]

olegy123
Зачем подмешивать в xml строки для дальнейшего ручного парсенья? пусть это будет более многословно, но раздельно

>>Всё одно и тоже.
да это одно и тоже, вид сбоку. Разница только в том что в случае не xml нужно писать свой парсер, что в общем случае - довольно сложно

[vitaly_l]

писать свой парсер, что в общем случае - довольно сложно

Это конечно же: да!!!

Но когда объём полезных передаваемых данных гигабайт, да к ним ещё прибавляется 5Гб от XML, то становится проще написать свой парсер, нежели заставить PC обработать такой объём мусора.

.

[olegy123]

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

<object left=100 top=200 button=300 right=500 width=400 height=100>
   <img data="png:base64:...">
   <img data="png:base64:...">
   <img data="jpg:base64:...">
   <img data="tiff:base64:...">
   <img src="http://..">
   <zip  data="base64:...">
<object/>

[zub]

>>полезных передаваемых данных гигабайт, да к ним ещё прибавляется 5Гб от XML
А тут на лицо и txt и xml головного мозга. надо полечить binary инъекциями

[olegy123]

Зачем подмешивать в xml строки для дальнейшего ручного парсенья? пусть это будет более многословно, но раздельно

Можно и не мешать.. Я усложнил. Завел в строку raw данные. Сейчас так кодируют картинки в HTML документе.
<img type="png" code="base64" data="..." />

Добавлено спустя 3 минуты 45 секунд:

писать свой парсер, что в общем случае - довольно сложно

Это конечно же: да!!!

Но когда объём полезных передаваемых данных гигабайт, да к ним ещё прибавляется 5Гб от XML, то становится проще написать свой парсер, нежели заставить PC обработать такой объём мусора.

Жду от тебя парсер.
Но чтобы у объекта (Object) были свойства и возможность добавлять произвольно зависимые (Object) и (Array)
Ну и чтобы название у (Object) были произвольные.. Не добавлять же поля свойств Name/Caption в <img>

Добавлено спустя 3 минуты 46 секунд:

>>полезных передаваемых данных гигабайт, да к ним ещё прибавляется 5Гб от XML
А тут на лицо и txt и xml головного мозга. надо полечить binary инъекциями

А можно ли вывести результат из XML:
Объект(здание) ->Этаж->Эл.Щитки(список) ?

[vitaly_l]

Я усложнил. Завел в строку raw данные. Сейчас так кодируют

У вас просто мало реального опыта. На самом деле в поставленной задаче - нет ничего сложного.

Жду от тебя парсер.

Щаз-з-з-з всё брошу и начну писать парсер - учитесь уже программировать, сами!
А то всё на халяву хотят получить!

[zub]

olegy123
>>Жду от тебя парсер.
>>Но чтобы...
Перегибать тоже ненадо, какбы структура предлагаемая Виталиком предполагает десериализацию непосредственно в эти самые обжекты. А вот xml распарсится в дерево xmlнодов (или чето подобное) и на этапе преобразования этого дерева в обжекты произвольные имена свойств уйдут в баню, останутся только те что поддержал программист

Завязываем офтопик. в топике описание тулбаров http://svn.shamangrad.net/zcad/trunk/ca ... layout.xml тэг ToolBarsConfig и формы не крадущие фокус при нажатии кнопок на них. а также предложения, жалобы, патчи...

Добавлено спустя 2 минуты 19 секунд:
>>А можно ли вывести результат из XML:
>>Объект(здание) ->Этаж->Эл.Щитки(список) ?
непонял что куда и из какой XML

[olegy123]

Перегибать тоже ненадо, какбы структура предлагаемая Виталиком предполагает десериализацию непосредственно в эти самые обжекты.

Виталик предложил свой удобный вариант. Который на самом деле не удобный, когда изначально до конца не продумана конечная структура элементов и их зависимости..
У него все тот же XML только очень сильно сокращенный ка пример: Object .. end; на самом деле описывается в xml так <Object> </Object>..

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

Это хорошо. зачем мне открывать то что мне не нужно, легко пропускаю.

>>А можно ли вывести результат из XML:
>>Объект(здание) ->Этаж->Эл.Щитки(список) ?
непонял что куда и из какой XML

Я про XPath
https://ru.wikipedia.org/wiki/XPath
где файл XML превращается в базу данных. например нужно подсчитать количество щитков на этаже..

[vitaly_l]

Виталик предложил свой удобный вариант. Который на самом деле не удобный, когда изначально до конца не продумана конечная структура элементов и их зависимости..
У него все тот же XML только очень сильно сокращенный ка пример: Object .. end; на самом деле описывается в xml так <Object> </Object>..

Откройте текстовым редактором файл .lfm из любого вашего проекта и убедитесь там, что Виталик - ничего не придумывал, а предложил взять за основу формат используемый Лазарусом. И парсер, который всё это считывает - есть в исходниках Лазаруса.

НО постольку поскольку, уже сделано на XML, то менять шило на мыло - нет смысла, т.к. там маленькие объёмы.

.

[zub]

>>где файл XML превращается в базу данных
Предлагаете XML как внутренний формат данных а не как средство хранения на диске?

Добавлено спустя 6 часов 27 минут 24 секунды:
Почитал интернеты - для предотвращения воровства фокуса в делфи есть TСontrol.OnMouseActivate, в лцл ессно такой роскоши нет(( https://bugs.freepascal.org/view.php?id=32246

Добавлено спустя 18 минут 37 секунд:
Формат хрнения тулбаров чуток поменял по образу и подобию анхордокинга

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

  <ToolBarsConfig ItemCount="5">
    <Item0 Name="CoolBarU" Type="CoolBar" ItemCount="1">
      <Item0 Name="Standart" Type="ToolBar"/>
    </Item0>
    <Item1 Name="CoolBarL" Type="CoolBar" ItemCount="0"/>
    <Item2 Name="CoolBarR" Type="CoolBar" ItemCount="0"/>
    <Item3 Name="CoolBarD" Type="CoolBar" ItemCount="0"/>
    <Item4 Name="Right" Type="FloatToolBar" BoundsRectTop="106" BoundsRectLeft="819" BoundsRectRight="847" BoundsRectBottom="619"/>
  </ToolBarsConfig>

Там в основе лежит TConfigStorage, xml лишь обертка для хранения на диске

Добавлено спустя 1 час 11 минут 25 секунд:
анхордокинг на панель добавили в транк! :drunk:

[debi12345]

По части хранения данных можно и поизвращаться. Если оные текстовые, то можно сделать как например в ОС/2 хэлп-файлах:
- хранить отдельные слова в словаре слов
- текст хранить как набор индексов слов в этом словаре

В результате имеем:
Плюсы:
- в несколько раз меньший размер
- встроенная реализация поиска

Минус:
- любое, даже самое малое, добавление текста требует предварительного поиска во всем словаре слов

[olegy123]

>>где файл XML превращается в базу данных
Предлагаете XML как внутренний формат данных а не как средство хранения на диске?

XML - это структурный вид хранения данных(база знаний). Если есть структура, зависимости одного от другого, группировки, деревья, связи - то пока нет иных вариантов кроме SQL.

Добавлено спустя 3 минуты 5 секунд:

По части хранения данных можно и поизвращаться. Если оные текстовые, то можно сделать как например в ОС/2 хэлп-файлах:
- хранить отдельные слова в словаре слов
- текст хранить как набор индексов слов в этом словаре

зачем оно нужно? сейчас когда флешка 32Гб забарахлила - выкинул.

[zub]

>>зависимости одного от другого, группировки, деревья, связи - то пока нет иных вариантов кроме SQL
СУБД ГМ)) как это нет - внутренний формат должен быть свой, наиболее оптимально подходящий под требуемые задачи, а не чтото универсальной

[MylnikovDm]

SQL это язык запросов к реляционной СУБД, а не формат хранения данных. У каждого сервера БД своя внутренняя структура хранения, причём достаточно сложная и весьма заметно отличающаяся от сервера к серверу.

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

Если какой-то файл будет использоваться как служебный только внутри данной конкретной программы, то упираться в использование именно XML никакого смысла нет. В рассматриваемом случае программа должна уметь сохранить состояние перед завершением работы, а также уметь считывать и восстанавливать это состояние при следующем запуске. А каким образом она будет это делать, для конечного пользователя соврешенно фиолетово. Так что тут главное, что удобнее и быстрее для конкрентного программиста. Например, можно вообще не использовать нкиакие тэги и прочие управляющие символы, а просто писать в строку подряд те парамтеры, которые небходимо сохранить, а потом считывать их в том же самом порядке используя стандартные функции чтения/записи строк.