LINUX.ORG.RU

SAX парсер

 , ,


0

2

Кто пользуется этой штукой в Java для рядовых задач, объясните, зачем так сложно? т.е. даже не сложно, а низкоуровнево? неужели никак не абстрагироваться от ручного разбора токенов? да, и вообще, вам не кажется что это коряво - раскидывать логику чтения одного элементы в две функции, для открывающего и закрывающего тега, к примеру?

По поводу уровня абстрагции, ну терпимо, мне кажется, когда можно или обрабатывать уже распарсенные элементы или писать запросы по xml(как к примеру в XmlDocument для .Net), ну уж точно не трогать руками отдельно токен начала, токен конца и подсчитывать вложенность.

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

да, и вообще, вам не кажется что это коряво - раскидывать логику чтения одного элементы в две функции, для открывающего и закрывающего тега, к примеру?

А как ты хотел? У закрывающего нет аргументов, поэтому его можно вынести в отдельный метод. А пихать все в один большущий смысла нет, все равно в своем коде ты их разнесешь.

подсчитывать вложенность

Это делает DOM-парсер. Но он держит все дерево в памяти, что не всегда приемлемо.

vurdalak ★★★★★
()

Если ты ищешь аналог XmlReader, то по-моему наиболее близким будет XMLStreamReader, введенный в JDK 1.6, хотя мне попадались и неофициальные библиотеки, но названия их не помню. А для DOM в java есть отдельный парсер.

dave ★★★★★
()

По поводу уровня абстрагции, ну терпимо, мне кажется, когда можно или обрабатывать уже распарсенные элементы или писать запросы по xml(как к примеру в XmlDocument для .Net), ну уж точно не трогать руками отдельно токен начала, токен конца и подсчитывать вложенность.

Ну так для таких штук придумали dom и xpath по нему. А sax - штука низкоуровневая и на практике применяется в довольно ограниченном количестве use cases, в основном при обработке огромных (сотни мегабайт) объемов данных.

Nagwal ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.