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

Question

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

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

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

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

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

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

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

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

Answer 1

Мы сделали это в нашем встроенном XML-редакторе Xopus. Вы можете увидеть пример here. Загрузим исходный 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

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

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

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