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

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

Это для указания ссылки на часть объекта, который сам по себе является XML-документом. Подразумевает, что:
а) у нас есть URI
б) этот URI является XML

Тут же рассматривается другой случай, когда нам нужно получить, грубо говоря, набор URI из чего-то, что напоминает DOM-дерево (информационная система)

Хотя в основе — www.w3.org/TR/xptr-xpointer/ — тот же XPath.
вот именно. это расширение xpath. с поддержкой диапазонов, фоллбэков, пространств имён и пр…
Пространства имён пока не были нужны, функционала основного XPath хватало :)
Штука, конечно, интересная. Но у меня есть некоторые сомнения, что ею так уж удобно пользоваться. Часто всякие надстройки приводят к тому, что приходится изучать собственный язык шаблонизатора (в данном случае XSLT), потом еще основной язык, к которому в конечном счете приводится шаблон (в данном случае SQL), да плюс еще особенности преобразований шаблонов к исходному коду. Не думаю что системный инженер, знакомый с Java/PHP/.NET не способен изучить несколько SQL команд (для удобства можно использовать специальные view для пользователей, чтобы не замораживать структуру таблиц).

Мне это напоминает стиль поборника абстракции: «Любая бизнес-логика приложения спрятана в каком-то конфигурационном xml-файле где-то в репозитории».
1) Язык шаблонизатора (XSLT) является основным языком CMS Arp.Site. С точки зрения верстальщика он является конечным языком и не сводится ни к SQL, ни к исходному коду — стандарт XSLT реализован полностью и не расширен с помощью функций. То есть изучить надо только XSLT (ну и HTML), а XPath является его частью.

2) Если же мы говорим о системе управления предприятием, то инженер-настройщик часто в начале не знает ни Java, ни SQL, ни структуры таблиц. Он знает только бизнес-модель, и описать её в терминах XPath'а ему чаще проще, чем в SQL.
У меня какое-то смешанное чувство. С одной стороны XPath дает уникальную гибкость приложению. Тем более что Arp.Site реализован на Java и настройщику будет сложно «чуть допилить». С другой стороны…

В первом случае верстальщик занимается программированием, но на более привычном ему языке. Во втором случае бизнес-логика оказывается внутри XSLT-шаблона представления. Наверняка дело не ограничится получением и представлением данных, потребуется некоторая обработка. В итоге модель, контроллер и представление (MVC) окажутся неотделимы друг от друга.

Первая же картинка по запросу «Arp.Site»:
КПЗ Arp.Site
Бизнес-кода в XSLT нет, поэтому никакой дополнительной обработки в XSLT, кроме преобразования в HTML/PDF/PNG/SVG не происходит.

Вся бизнес-логика реализована на Java. И это жёстко — XSLT-преобразование просто не может ничего сделать в системе, для этого нет ни API, ни функций расширения.

P.S.: Пользуйтесь Google, он красивее картинки ищет :)
P.P.S: Возможно, стоит сделать топик о том, как сделана система Arp.Site в большом масштабе, где там разделение Data/Business/View
Цитирую: «Например, возможно, что после выбора города поставщика нужно ограничивать список поставщиков». Зависимости поставщиков от города — это бизнес-уровень. В данном случае он оказывается в шаблоне представления.

Расскажите про Arp.Site. Мне интересна архитектура.

1) Нет, в данном случае зависимость описывается на уровне модели. То есть где-то описывается модель класса «Сотрудник», у которого есть атрибуты «Страна», «Офис». Но атрибуты и их свойства задаются, например, через Web-интерфейс (или GUI) системным инженером, не имеющим отношения к программированию. И связь эта обычно задаётся с помощью SQL.

2) Ок, в отдельном топике.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории