SVG через динамический XML + XSL

Question

Это немного смутное представление, которое я перебирал в своей голове, и которое мне очень любопытно, если есть элегантный метод решения. Возможно, это следует воспринимать как мысленный эксперимент.

Представьте, что у вас есть схема XML с соответствующим XSL-преобразованием, которое отображает XML как SVG в браузере. XSL генерирует SVG с соответствующими обработчиками Javascript, которые, в конечном счете, реализуют функциональность, подобную редактированию, так что свойства объектов или их расположения на холсте SVG могут редактироваться пользователем. Например, элемент можно перетащить из одного места в другое.

Теперь, это не особенно сложно - пример перетаскивания - это просто вопрос изменения (x, y) координат SVG-объекта, или операция изменения размера будет простым вопросом изменения его ширины или высоты .

Но есть ли элегантный способ заставить Javascript работать с DOM XML-документа source вместо визуализированного SVG? Почему ты спрашиваешь? Хорошо, представьте, что у вас есть очень сложные XSL-преобразования, в которых изменение одного свойства приводит к сложным изменениям в SVG. Вы хотите сохранить простоту в своем коде Javascript, но также и простой способ сохранить измененный XML обратно на сервер.

Некоторые возможности того, как это может функционировать:

1. После модификации исходного DOM просто перезапустите XSL-преобразование и замените оригинал. Недостаток : перебор, потенциально дорогостоящая операция.
2. Создайте соглашения об именах идентификаторов / классов в исходном и целевом XML / SVG, чтобы элементы могли быть связаны друг с другом, и выполняйте XSL-преобразование только в подмножестве нового DOM. Другими словами, измените временный DOM, примените к нему XSL, удалите измененные элементы из SVG и вставьте новый. Недостатки : Может быть невозможно применить XSL к временным DOM в браузере (?). Кроме того, возможно, немного запутанный или некрасивый в обслуживании.

Я думаю, что, возможно, можно придумать структуру, которая обрабатывает второй сценарий, но задача будет сделать его легким и не сильно привязанным к реальной XML-схеме. Есть идеи или другие возможности? Или, может быть, существует существующий способ сделать это, о котором я не знаю?

ОБНОВЛЕНИЕ : Чтобы уточнить, как я уже упоминал в комментарии ниже, это помогает отделить код рисования от кода редактирования. Для более конкретного примера того, как это полезно, представьте элемент, который определяет способ его рисования в зависимости от значения свойства соседнего элемента. Эту логику лучше сжать непосредственно в коде отрисовки, а не дублировать ее в коде редактирования.

Answer 1

Мы сделали это в нашем редакторе XML в браузере Xopus. Вы можете увидеть пример здесь . Мы загружаем исходный документ XML, схему XML и XSLT, который выводит HTML + SVG. Внутренне мы переписываем ваш XSLT в XSLT ', что позволит нам отслеживать вывод HTML + SVG обратно в исходный XML, который был контекстом в XSL, для вывода этого узла HTML или SVG. Это та структура, на которую вы ссылаетесь.

Чтобы упростить редактирование, мы наведем курсор на вывод XSLT и обновим XML DOM при вводе или вставке элементов. После каждого изменения мы будем запускать XSLT. По соображениям производительности мы сравним вывод XSLT с предыдущим выводом и применим изменения с использованием операций HTML DOM к представлению WYSIWYG.

Различаем два выхода XSLT, используя другой XSLT. Мы можем сделать это, потому что мы изменили исходный XSLT (в результате XSLT '), чтобы он выводил уникальные и постоянные идентификаторы для каждого выходного узла. Таким образом, все новые узлы будут иметь новые идентификаторы, а отсутствующие идентификаторы удаляются узлами.

XSLT '- это переписанная версия оригинального XSLT, который вы предоставляете. Это все еще XSLT, но мы добавили несколько вещей, чтобы он выводил идентификаторы для всех выходных узлов (мы делаем это с еще одним XSLT). Кроме того, он функционально эквивалентен вашему оригинальному XSLT.

Answer 2

Может использовать can AJAX: вместо локального редактирования документа отправьте команды редактирования исходного XML на сервер, который снова преобразуется, а затем отправит новый SVG обратно.

Основной проблемой здесь будет то, что происходит, когда вы обновляете элемент SVG на текущей странице. Будет ли drag'n'drop все еще чувствовать себя гладко? Если нет, то вам, возможно, придется прибегнуть к сочетанию двух методов: перетащите узел SVG с помощью JavaScript, а когда пользователь отбросит узел, отправьте обновление на сервер для нового SVG.

Вы не захотите пытаться синхронизировать обновления в XML и локальном SVG (что будет означать репликацию части XSLT в JavaScript -> оставаться в одном мире, не смешивать).