Всё одно и тоже. Точно также можно извлекать или не извлекать. XML - примитивный громоздкий формат, который легко заменяется нормальным. Просто те кто создавал XML - не умели думать и содрали всё с другого формата, а остальные подхватили "мол круто", а на самом деле ГРОМОЗДКО!!!
olegy123 Зачем подмешивать в xml строки для дальнейшего ручного парсенья? пусть это будет более многословно, но раздельно
>>Всё одно и тоже. да это одно и тоже, вид сбоку. Разница только в том что в случае не xml нужно писать свой парсер, что в общем случае - довольно сложно
zub писал(а):писать свой парсер, что в общем случае - довольно сложно
Это конечно же: да!!!
Но когда объём полезных передаваемых данных гигабайт, да к ним ещё прибавляется 5Гб от XML, то становится проще написать свой парсер, нежели заставить PC обработать такой объём мусора.
>>полезных передаваемых данных гигабайт, да к ним ещё прибавляется 5Гб от XML А тут на лицо и txt и xml головного мозга. надо полечить binary инъекциями
Последний раз редактировалось zub 06.08.2017 13:46:17, всего редактировалось 3 раза.
zub писал(а):Зачем подмешивать в xml строки для дальнейшего ручного парсенья? пусть это будет более многословно, но раздельно
Можно и не мешать.. Я усложнил. Завел в строку raw данные. Сейчас так кодируют картинки в HTML документе. <img type="png" code="base64" data="..." />
Добавлено спустя 3 минуты 45 секунд:
vitaly_l писал(а):
zub писал(а):писать свой парсер, что в общем случае - довольно сложно
Это конечно же: да!!!
Но когда объём полезных передаваемых данных гигабайт, да к ним ещё прибавляется 5Гб от XML, то становится проще написать свой парсер, нежели заставить PC обработать такой объём мусора.
Жду от тебя парсер. Но чтобы у объекта (Object) были свойства и возможность добавлять произвольно зависимые (Object) и (Array) Ну и чтобы название у (Object) были произвольные.. Не добавлять же поля свойств Name/Caption в <img>
Добавлено спустя 3 минуты 46 секунд:
zub писал(а):>>полезных передаваемых данных гигабайт, да к ним ещё прибавляется 5Гб от XML А тут на лицо и txt и xml головного мозга. надо полечить binary инъекциями
А можно ли вывести результат из XML: Объект(здание) ->Этаж->Эл.Щитки(список) ?
olegy123 >>Жду от тебя парсер. >>Но чтобы... Перегибать тоже ненадо, какбы структура предлагаемая Виталиком предполагает десериализацию непосредственно в эти самые обжекты. А вот xml распарсится в дерево xmlнодов (или чето подобное) и на этапе преобразования этого дерева в обжекты произвольные имена свойств уйдут в баню, останутся только те что поддержал программист
Добавлено спустя 2 минуты 19 секунд: >>А можно ли вывести результат из XML: >>Объект(здание) ->Этаж->Эл.Щитки(список) ? непонял что куда и из какой XML
zub писал(а):Перегибать тоже ненадо, какбы структура предлагаемая Виталиком предполагает десериализацию непосредственно в эти самые обжекты.
Виталик предложил свой удобный вариант. Который на самом деле не удобный, когда изначально до конца не продумана конечная структура элементов и их зависимости.. У него все тот же XML только очень сильно сокращенный ка пример: Object .. end; на самом деле описывается в xml так <Object> </Object>..
zub писал(а):обжекты произвольные имена свойств уйдут в баню, останутся только те что поддержал программист
Это хорошо. зачем мне открывать то что мне не нужно, легко пропускаю.
zub писал(а):>>А можно ли вывести результат из XML: >>Объект(здание) ->Этаж->Эл.Щитки(список) ? непонял что куда и из какой XML
Я про XPath https://ru.wikipedia.org/wiki/XPath где файл XML превращается в базу данных. например нужно подсчитать количество щитков на этаже..
olegy123 писал(а):Виталик предложил свой удобный вариант. Который на самом деле не удобный, когда изначально до конца не продумана конечная структура элементов и их зависимости.. У него все тот же XML только очень сильно сокращенный ка пример: Object .. end; на самом деле описывается в xml так <Object> </Object>..
Откройте текстовым редактором файл .lfm из любого вашего проекта и убедитесь там, что Виталик - ничего не придумывал, а предложил взять за основу формат используемый Лазарусом. И парсер, который всё это считывает - есть в исходниках Лазаруса.
НО постольку поскольку, уже сделано на XML, то менять шило на мыло - нет смысла, т.к. там маленькие объёмы.
>>где файл XML превращается в базу данных Предлагаете XML как внутренний формат данных а не как средство хранения на диске?
Добавлено спустя 6 часов 27 минут 24 секунды: Почитал интернеты - для предотвращения воровства фокуса в делфи есть TСontrol.OnMouseActivate, в лцл ессно такой роскоши нет(( https://bugs.freepascal.org/view.php?id=32246
Добавлено спустя 18 минут 37 секунд: Формат хрнения тулбаров чуток поменял по образу и подобию анхордокинга
По части хранения данных можно и поизвращаться. Если оные текстовые, то можно сделать как например в ОС/2 хэлп-файлах: - хранить отдельные слова в словаре слов - текст хранить как набор индексов слов в этом словаре
В результате имеем: Плюсы: - в несколько раз меньший размер - встроенная реализация поиска
Минус: - любое, даже самое малое, добавление текста требует предварительного поиска во всем словаре слов
zub писал(а):>>где файл XML превращается в базу данных Предлагаете XML как внутренний формат данных а не как средство хранения на диске?
XML - это структурный вид хранения данных(база знаний). Если есть структура, зависимости одного от другого, группировки, деревья, связи - то пока нет иных вариантов кроме SQL.
Добавлено спустя 3 минуты 5 секунд:
debi12345 писал(а):По части хранения данных можно и поизвращаться. Если оные текстовые, то можно сделать как например в ОС/2 хэлп-файлах: - хранить отдельные слова в словаре слов - текст хранить как набор индексов слов в этом словаре
зачем оно нужно? сейчас когда флешка 32Гб забарахлила - выкинул.
>>зависимости одного от другого, группировки, деревья, связи - то пока нет иных вариантов кроме SQL СУБД ГМ)) как это нет - внутренний формат должен быть свой, наиболее оптимально подходящий под требуемые задачи, а не чтото универсальной
SQL это язык запросов к реляционной СУБД, а не формат хранения данных. У каждого сервера БД своя внутренняя структура хранения, причём достаточно сложная и весьма заметно отличающаяся от сервера к серверу.
XML хорошо подходит только в качестве универсального обменного формата данными, но как формат хранения сложных структур, тем более больших, он не подходит. А если требуется прямой доступ к блокам данных по индексу внутри файла, то XML вообще нельзя использовать, поскольку прежде чем его можно будет использовать, его необходимо загрузить и распарсить как минимум до требуемого места. То есть, это система последовательного чтения/записи, для которой прямой доступ к внутренним фрагментам файла невозможен.
Если какой-то файл будет использоваться как служебный только внутри данной конкретной программы, то упираться в использование именно XML никакого смысла нет. В рассматриваемом случае программа должна уметь сохранить состояние перед завершением работы, а также уметь считывать и восстанавливать это состояние при следующем запуске. А каким образом она будет это делать, для конечного пользователя соврешенно фиолетово. Так что тут главное, что удобнее и быстрее для конкрентного программиста. Например, можно вообще не использовать нкиакие тэги и прочие управляющие символы, а просто писать в строку подряд те парамтеры, которые небходимо сохранить, а потом считывать их в том же самом порядке используя стандартные функции чтения/записи строк.