Как стать автором
Обновить

Комментарии 10

Насколько альтернативных вариантов:

Использовать аналог NSXMLDocument – KissXML

Или через XSLT на сервере или iphone (последнее, несколько сложнее, но вполне решаемо) приводить XML к DTD PropertyList-1.0, и парсить штатными средствами.
+1 зы KissXML. Во-первых, его классы совместимы с маковскими NSXML… анлогами, что дает надежду на замену нативными средствами в будущем. А во-вторых, та самая структура результатов, о которой упоминул автор, дает возможность более удобной обработки. Так тривиальная и постоянно встречающаяся задача «вытащить все элементы item из result», решаемая вызовом единственного метода, при описанном в статье подход превращается у увлекаельное итерирование по всем элементам child, на сколько я понимаю.
предложите вариант при котором не потребуется итерированный проход по всем child?
мне это видится в виде рекурсивного прохода по NSDictionary и метод в 5 строк, Вы что то другое можете предложить?
Навероное плохо выразился или недопонял суть статьи.

Насколько я понял, Вами предлагается иметь на входе массив данных в формате XML, на выходе — словарь предложенной структуры. Я всего лишь заметил, что с таким выходом работать нелегко. Конечно под капотом потребуется итерация (хотя наверняка можно придумать, более быстрые варианты, чем обход всех детей в поисках нужных) по внутренним элементам, но суть моего предложения — поиметь удобные методы для работы, типа:

[(DDXMLElement *) root elementsForName:@«item»];

Всегда можно сказать: «надо всего лишь описать метод в 5 строк для выборки», а потом «дополнительная индексация прикручивается за 2 хода» и закончить «ничего не мешает объединить это все в единый класс». Я же говорю всего лишь о возможности сразу взять готовый набор классов и методов (с потенциальной возможностью выкинуть этот код безболезненно в будущих версиях SDK).
естественно, взять готовый класс всегда проще, но иногда не интересно, это раз.
я показал свой вариант преобразования xml в словарь, а не класс, который позволить оперировать xml как только душе захочется, это два.
по поводу удобства — субъективное мнение и, опять же, как вы заметили, все дописывается под нужды, у меня нужды искать все item в result нет. еще раз повторюсь, я не стремился показать готовый класс для работы с xml.
и с чего такая уверенность, что в будущих версиях сдк не будет libxml?
Ну, значит я изначально не ошибся и Вы позиционируете данное решние как готовое.
Тогда первый комментарий в силе, и я продолжаю утверждать, что предложенным на выход форматом пользоваться неудобно (ага, это мое субъективное мнение, но я был бы рад услышать о перпендикулярных критериях удобства). Я уж не знаю какие нужды у Вас, если даже искать все item в result нет подтребности, но обычно хотя бы такие вызовы бывают нужны (наряду с получить значение аттрибута в виде строки/числа/boolean).

Общие замечания:
— Вы же хотели «поделиться своим решением парсинга XML», а не научить писать самому ради интереса, правильно?
— Обычно «парсинг» предполагает более-менее универсальную форму, подходящую под множество прикладных задач. Писать отдельный парсер под каждую микрозадачу — это наверное «интересно» и уж точно «не проще», но и цель не ясна ;)

P.S. Последнего предложения я не понял вовсе, потому что а) обычно стараются использовать наиболее высокоуровневые возможности (т.е. классы Objective-C в данном случае) и б) насколько я понимаю, libxml и так доступен, и всегда таковым был.
начинается бесполезный спор…
ни где по тексту у меня нет упоминания что это «готовое универсальное решение для работы с XML», это всего лишь способ «перевести» XML в NSDictionary
«обычно стараются использовать наиболее высокоуровневые возможности» — в статье указаны два метода класса, который у меня является «высокоуровневой» оберткой, как то так, в результате я работаю с классом obj-c, а не напрямую с библиотекой libxml, помоему тут все в порядке.
«Я же говорю всего лишь о возможности сразу взять готовый набор классов и методов (с потенциальной возможностью выкинуть этот код безболезненно в будущих версиях SDK). » — вот это я видимо не совсем понял, поэтому и вы не поняли мое последнее предложение
А вот такой вопрос есть. Если стримить XML из интернета и парсить на лету, при помощи стандартного SAX-парсера (что адекватнее, так как меньше памяти используется), то у того же стандартного парсера есть проблема с кодировками (он всегда предполагает utf-8 кажется, вне зависимости от того, что прописано в начале файла). Какое-то решение есть?
сейчас не за маком и налету парсить не пробовал
насколько помнится вопрос с кодировкой решал при помощи такого костыля: перегонял nsdata в строку с указанием кодировки, в которой xml, потом перегонял из строки в nsdata
что то типа этого:
NSString *str = [[NSString alloc] initWithData:winData encoding:NSWindowsCP1251StringEncoding];
NSData *utfData = [st dataUsingEncoding:NSUTF8StringEncoding];
А что NSXMLParser уже отменили? Это тоже неплохой класс для разбора XML и не должен генерить ликов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории