Сегодня мы публикуем статью , человека, который недавно начал изучать Java. Думаю, что это будет интересно таким же новичкам, как и он. Итак, встречайте AlexNNovak.
Работа с XML, что же в этом направлении на сегодняшний момент времени написано очень много статей с примерами и примеров со статьями, некоторое из них лучше, некоторые хуже, некоторые можно сказать совсем отвратительные. Отвратительные они в том плане, что читающий их человек может совершенно бездумно скопировать пример описанный в статье и так же, не задумываясь и не углубляясь в подробности изменив два значения его использовать. «А что в этом плохого?» совершенно справедливо спросите Вы, «Взял мол, готовый кусок кода, подправил под свои потребности и используй!», вот тут то и заключается «плохо». Используя чужой код Вы отвыкаете думать сами, и я не подразумеваю библиотеки сторонних разработчиков, я имею ввиду конкретно код примеров из статей. Ну да ладно, я отвлекся и хватил немного в сторону.
Итак, я не претендую на ни на истину ни на велосипед, но, перед тем как начать работу с великим и могучим XML-ем нам надо сперва определить, какое действие с ним, мы хотим выполнить, а именно: создать XML документ – записать некие данные использую определённую структуру или наоборот разобрать(parse) XML документ – из готового документа подчиненного строгой структуре извлечь интересующие нас данные. Когда мы определились, что именно мы хотим делать, мы должны понять, какими методом в данной конкретной ситуации нам удобнее и/или правильнее поступать.
Признаюсь честно, что с созданием XML документов мне пока сталкиваться не приходилось, посему буду описывать методы, к которым прибегал и которые, как я считаю для совсем уж начинающего Java программиста или QA Automation инженера самые быстрые в освоении и понимании. Итак, я выбрал два основных метода: это DOM и XPath.
Начну, пожалуй, с XPath– этот метод удобен в том случае если Вам надо в очень краткие сроки разобрать «по полочкам» документ структура которого (название нод и т.д.) стабильна и не будет в ближайшем обозримом будущем меняться. Недостатком же данного метода в первую очередь я вижу то, что в коде Вашего приложения придётся очень много очень много «хардкодить». А это подразумевает под собой то, что Ваше приложение будет не очень гибким. Конечно я так же беру в расчет и тот факт, что Javaпревосходно ладит с XPathQueryv.1, что может обеспечить немного больше гибкости и универсальности, но даже этот факт не даст Вам уйти от «хардкодинга».
DOM – этот метод несколько сложнее в освоении но и гибче чем описанный выше. И если метод XPathпредполагает что пользователь точно знает путь, ну или хотя бы часть пути к ноде содержащей интересующую его информацию, то DOMпозволяет разбирать наш XML, обладая намного меньшим количеством информации. Например, нам будет достаточно знать, что имя ноды содержит в себе определённые символы, а вся остальная работа по нахождению нужной нам информации в недрах XML документа перекладывается непосредственно на плечи машины.
К написанию данного материала меня подтолкнула задача, поставленная передо мной, и заставившая испытать известные проблемы с кирпичами. В общем надо было мне разобрать один документ, если точнее XSDсхему, и на основе полученных результатов создать экселевскую таблицу. И как я к своей XSD-шке не подходил, с какой стороны не брался за неё, ну ни в какую она не сдавалась. Основной загвоздкой этого задания, как оказалось, было то, что имя ноды в XSDдокументе содежит префикс вида «xsd:» или «xs:»(что не имеет существенного значения). И вот пока этот префикс не вырезан, ни один из методов не хочет адекватно работать со структурой документа, DOMне строится, не ведёт XPathтак сказать. К тому моменту, когда я понял, в чем заключается основа моих неудач, я успел перечитать больше тридцати разных статей и извести глупыми вопросами всех программистов, с которыми работаю. Я рассмотрел и попытался применить массу разных подходов и метался от «объясни, расскажи, покажи» до копипасты примеров из статей. В то же самое время я заметил, что материал, который смог бы помочь, или даже подсказать разработчику, какой метод ему на самом деле, в данный конкретный момент, лучше использовать, отсутствует как таковой. Что и привело меня в конечном итоге к написанию данной статьи.
Я специально старался не приводить примеров кода, так как найти подходящий для Вашего случая не составит большого труда, и статья эта задумывалась скорее не как учебный материал по работе с XML, а скорее как простой помощник в выборе того метода который поможет Вам сэкономить время и нервы.
