Есть ли API JavaScript для привязки XML - аналог JAXB для Java?

В Java мы много работаем с JAXB2. Сопоставления Object‹->XML определяются как аннотации в классах Java:

@XmlRootElement(name="usertask", namespace="urn:test")
public class UserTask
{
    @XmlElement(namespace="urn:test")
    public String getAssignee() { ... }

    public void setAssignee(String assignee) { ... }
}

Среда выполнения JAXB может считывать эти аннотации и создавать демаршаллер для разбора XML в экземпляр объекта или маршалинга объекта в XML.

JAXB поставляет компилятор схемы (XJC), который может генерировать аннотированные классы из XML-схем, что является еще одной замечательной функцией.


В последнее время мы много работали с клиентским JavaScript. Нам также нужна обработка XML там. Например, нам нужно проанализировать документы WPS, такие как этот. Эти документы также соответствуют различным схемам XML (вот схема WPS 1.0.0 для образца XML). Было бы здорово работать с объектами JavaScript вместо XML, это экономит огромные усилия. В некоторых случаях мы можем использовать решения на основе JSON, такие как DWR, но во многих случаях нам приходится обрабатывать XML на клиенте. боковая сторона.

Мой вопрос:

Есть ли аналог JAXB для JavaScript?

Какой-нибудь инструмент, который скомпилировал бы XML-схему в некоторое сопоставление объектов XML‹-> и предоставил бы среду выполнения для преобразования между объектами XML и JavaScript?

Я мог бы легко представить сопоставления, сгенерированные в такой форме, как:

UserTask = new JSXML.XmlRootElement({
  name: "usertask",
  namespace: "urn:test",
  properties: [
    {
      assignee: new JSXML.XmlElement({
        name: "assignee",
        namespace: "urn:test",
        type: new JSXML.XSD.String()
      })
    }
  ]
});

И этого должно быть достаточно, чтобы построить unmarshaller или marshaller.


person lexicore    schedule 29.09.2010    source источник


Ответы (4)


Как насчет поддержки JSON для JAXB? Повторно используйте ваши текущие классы моделей с аннотациями JAXB, но выводите JSON из ваших конечных точек REST.

Текущие версии Jersey поддерживают это (через jersey-json) с JSONJAXBContext.

Вы также можете попробовать Джексона JAXB и поддержка JAX-RS.

person sagemintblue    schedule 29.01.2011
comment
Поддержка JSON для JAXB — это именно то, что мне нужно. Но на стороне клиента, на чистом JavaScript. Джерси и Ко можно использовать на стороне сервера. Прямо сейчас у нас есть серверное решение на основе DWR, которое также отлично работает. Но мне нужно решение только для клиента (прокси-сервер на стороне сервера все еще в порядке). - person lexicore; 30.01.2011

На сегодняшний день я не нашел ничего похожего на то, что мне нужно. Поэтому я решил реализовать его сам. Вот страница проекта:

http://confluence.highsource.org/display/MISC/Jsonix

Проект размещен на GitHub:

https://github.com/highsource/jsonix/

person lexicore    schedule 27.10.2010

Я не пробовал это, поэтому я не уверен, что это сработает, но рассматривали ли вы возможность использования GWT, чтобы вы все еще могли использовать JAXB и писать все приложение как java-приложение? Я не уверен, поддерживает ли GWT JAXB (вероятно, нет), но может быть альтернатива для синтаксического анализа xml, которую он будет поддерживать. Если это сработает, вы можете автоматизировать создание моделей javascript с помощью gwt, а затем включить их в свое приложение. Да, это намного сложнее, чем вы хотите, но это лучше, чем писать его с нуля.

person Ben Taitelbaum    schedule 28.10.2010

Что вы можете сделать, так это добавить общее определение таблицы стилей: XSLT в свой XML, чтобы преобразовать их в JSON. например: http://code.google.com/p/xml2json-xslt/

Обработка XML с помощью Javascript является проблемой по сравнению с JSON, особенно в разных браузерах.
Таблица стилей добавит небольшие накладные расходы к вашему запросу. Вы можете выбрать на стороне сервера или клиента, но вы должны сравнить это со сложностью кода и скоростью анализа и чтения XML с помощью Javascript в разных браузерах.

person Mic    schedule 29.09.2010
comment
Решение XSLT не подходит по ряду причин. Во-первых, нам нужна обработка на стороне клиента. Использование XSLT-процессора для преобразования XML в JSON слишком тяжело, неприемлемо тяжело. Я думаю, что XSLT в любом случае не лучший выбор технологии: то, что можно сделать с помощью 7K XSLT, можно сделать с помощью 3K JavaScript, и вам не понадобится XSLT-процессор на стороне клиента. - person lexicore; 29.09.2010
comment
Во-вторых, XSLT, подобный тому, на который вы разместили ссылку, не зависит от схемы. Например, если у вас есть элемент ‹item›foo‹/item›, вы на самом деле не будете знать, должен ли это быть один элемент: 'foo' или элемент массива: ['foo']. Имея 2010 год, вы не знаете, год это или число и так далее. Отображение объектов XML‹-› здесь должно быть получено из схемы, чтобы предоставить соответствующую информацию о структуре и типе, которую экземпляр XML сам по себе не предоставляет. - person lexicore; 29.09.2010
comment
Добавление заголовка, такого как <?xml-stylesheet type="text/xml" href="xml2json.xsl"?>, в ваш XML понимается всеми браузерами без добавления чего-либо, или вы можете сделать это на стороне сервера (nginx действительно хорош в этом). Переход на JSON предполагает некоторые компромиссы, особенно в отношении схем, типов и т. д. Но для меня это стоит потери. - person Mic; 29.09.2010
comment
...стоит потери не имеет смысла. Вы предлагаете что-то, что на самом деле не соответствует тому, что хочет сделать ОП. - person deoxxa; 30.11.2013