Здравствуйте, luceus, Вы писали:
L>Всем привет!
L>Есть необходимость хранить данные в XML файле. При инициализации класса нужно загружать данные из файла.
L>Пример файла: L><xml...
L>... L><table> L> <field name="age" type="int"/> L> <field name="name" type="string"/> L> ... L></table>
L></xml>
L>Какой использовать для этого нужно модуль?
Здравствуйте, luceus, Вы писали:
L>Есть необходимость хранить данные в XML файле. При инициализации класса нужно загружать данные из файла. L>Пример файла:
(скип) L>Какой использовать для этого нужно модуль?
Здравствуйте, luceus, Вы писали:
L>Всем привет!
L>Есть необходимость хранить данные в XML файле. При инициализации класса нужно загружать данные из файла.
L>Пример файла: L><xml...
L>... L><table> L> <field name="age" type="int"/> L> <field name="name" type="string"/> L> ... L></table>
L></xml>
L>Какой использовать для этого нужно модуль?
Ну если схема файла сложнее чем key=value, то какой-нибудь JAXB, XMLBeans и т.п. Можно самому напрямую загружать используя DOM, SAX, StaX, что больше нравится. Для простых конфигов, класс Properties позволяет и в XML хранить настройки.
L>Есть необходимость хранить данные в XML файле. При инициализации класса нужно загружать данные из файла. L>Какой использовать для этого нужно модуль?
luceus пишет:
> Есть необходимость хранить данные в XML файле. При инициализации класса > нужно загружать данные из файла. > > Пример файла: > <xml...
Несколько ортогональный совет. Я пользовался в свое время половиной
из посоветованных здесь библиотек. Пришел к выводу, что если у тебя
структура XML меняется не очень часто — то делать только руками и
только SAX парсер. Делается это первый раз — день второй и
последующие — по два часа. Да Jakarta Commons Configuration.
выглядит солидно — но работает буквально в 50 раз медленнее, причем
разобраться с ней, и написать дескиптор загрузки занимает банально
больше времени, чем просто SAX.
Все эти библиотеки нужны при _очень_ разветвленной структуре файла
или когда файл сам по себе очень часто меняется.
Пользовался 3-мя разными библиотеками (Commons Configuration, JAXB,
Castor) плюнул уже два года — делаю руками через SAX
--
WBR Денис Цыплаков /* jabber UID: denis.tsyplakov@jabber.ru */
Знающий не говорит, говорящий не знает
Здравствуйте, Денис Цыплаков, Вы писали:
ДЦ> Пользовался 3-мя разными библиотеками (Commons Configuration, JAXB, ДЦ> Castor) плюнул уже два года — делаю руками через SAX
Lucker пишет:
> ДЦ> Пользовался 3-мя разными библиотеками (Commons Configuration, JAXB, > ДЦ> Castor) плюнул уже два года — делаю руками через SAX > > Digester-ом не пробовал?
О! Забыл и им пробовал. Даже XSD схему делал. Заводилось удручающе
медленно.
--
WBR Денис Цыплаков /* jabber UID: denis.tsyplakov@jabber.ru */
Знающий не говорит, говорящий не знает
Здравствуйте, Денис Цыплаков, Вы писали:
ДЦ>Lucker пишет:
>> ДЦ> Пользовался 3-мя разными библиотеками (Commons Configuration, JAXB, >> ДЦ> Castor) плюнул уже два года — делаю руками через SAX >> >> Digester-ом не пробовал?
ДЦ> О! Забыл и им пробовал. Даже XSD схему делал. Заводилось удручающе ДЦ> медленно.
Lucker пишет:
> ДЦ> О! Забыл и им пробовал. Даже XSD схему делал. Заводилось удручающе > ДЦ> медленно. > > Уверен что его пробовал? Нафига там XSD
Уверен. XSD служить для проверки правильности xml файла.
Например у меня есть такой конфиг
<Module role="r1" class="a.b.c.Class1"/>
<Module role="r2" class="a.b.c.Class1"/>
<Module role="r3" class="a.b.c.Class2"/>
Я хочу быть уверен, что имя роли уникально.
можно это делать при запихивании нового модуля в хэш
модулей. А можно описать требование в XSD и при запихивании
в хэш не проверять.
В общем-то XSD штука удобная, но очень уж тормозная. Если
XML меняется не часто — то лучше статичная проверка в коде.
При частых изменениях — проверки в коде — задолбаешься править
и тут уже лучше XSD
--
WBR Денис Цыплаков /* jabber UID: denis.tsyplakov@jabber.ru */
Знающий не говорит, говорящий не знает
Здравствуйте, Денис Цыплаков, Вы писали:
ДЦ> О! Забыл и им пробовал. Даже XSD схему делал. Заводилось удручающе ДЦ> медленно.
Денис, что-то Вы путаете.
Digester это очень простой маппинг объектов (в идеале JavaBean) на XML. Основан на SAX поэтому по скорости/ресурсам практически не проигрывает рукописному решению. Строковые запросы выглядят как XPath (или XPath и есть точно уже не помню) поэтому запись самого маппинга выглядит очень компактной.
Кроме этого маппинг очень гибкий: не обязательно маппить на JavaBeans можно просто на вызовы методов. То есть даже если объекты далеки от JavaBeans и стандартых коллекций, то их все равно не сложно замапить.
Здравствуйте, Денис Цыплаков, Вы писали:
>> Уверен что его пробовал? Нафига там XSD
ДЦ> Уверен. XSD служить для проверки правильности xml файла.
Для чего служит XSD я в курсе. Я не понимаю как он связан с Digester-ом. Нет, ну конечно xml перед разбороом в дигестере можно проверить схемой, однако если скорость этой проверки слишком удручающе выглядит, то это уж проблема парсера и верификатора, и при ручном разборе xml-я посредством SAX скорость будет выглядеть не менее удручающей.
Blazkowicz пишет:
> Денис, что-то Вы путаете. > Digester это очень простой маппинг объектов (в идеале JavaBean) на XML. > Основан на SAX поэтому по скорости/ресурсам практически не проигрывает > рукописному решению. Строковые запросы выглядят как XPath (или XPath и > есть точно уже не помню) поэтому запись самого маппинга выглядит очень > компактной. > > Кроме этого маппинг очень гибкий: не обязательно маппить на JavaBeans > можно просто на вызовы методов. То есть даже если объекты далеки от > JavaBeans и стандартых коллекций, то их все равно не сложно замапить.
Да нет не путаю я. Мапил я на вызовы методов. Если сечас подумать и
вспомнить — наверное тормоза действительно были от XSD. Если бы я
тогда просто XSD убрал бы — то заработало бы быстрее. Но что сделано
то сделано. Я убрал сразу весь Digester и отказался от XSD.
Наверное да. Внес я некую дезинформацию по поводу тормознутости
Digester-а. Прошу прощения за неточность.
Дело в общем-то прошлое — но в целом приложение мое упростилось.
Весь разбор в длинном, но простом файле. Там что-то вроде
if ((state == HandlerState.IDLE) && (localName.equals("Group")))
{
state = HandlerState.GROUP;
}
else if ((state == HandlerState.GROUP) &&
(localName.equals("Module")))
{
createModule(attributes);
state = HandlerState.MODULE;
}
--
WBR Денис Цыплаков /* jabber UID: denis.tsyplakov@jabber.ru */
Знающий не говорит, говорящий не знает
Здравствуйте, Денис Цыплаков, Вы писали:
ДЦ> Пришел к выводу, что если у тебя ДЦ> структура XML меняется не очень часто — то делать только руками и ДЦ> только SAX парсер.
Если уж делать руками то по мне так StAX намного удобнее SAX'а.
Использовал его в нескольких проектах.
Скорость примерно такая же как у SAX, так как это streaming API.
Но в отличие от SAX "обходят не тебя", а ты сам вызываешь next() или nextTag().
Кстати очеь удобная штука и для генерации XML.
korostoff пишет:
> ДЦ> Пришел к выводу, что если у тебя > ДЦ> структура XML меняется не очень часто — то делать только руками и > ДЦ> только SAX парсер. > > Если уж делать руками то по мне так StAX намного удобнее SAX'а. > Использовал его в нескольких проектах. > Скорость примерно такая же как у SAX, так как это streaming API. > Но в отличие от SAX "обходят не тебя", а ты сам вызываешь next() или > nextTag(). > Кстати очеь удобная штука и для генерации XML.
Спасибо, посмотрю на неделе.
--
WBR Денис Цыплаков /* jabber UID: denis.tsyplakov@jabber.ru */
Знающий не говорит, говорящий не знает
