UMI.CMS: сайт як набір XML-сервісів

1. Об'єкти системи в форматі XML
2. Результати роботи макросів в форматі XML
3. Вибірки з бази даних в форматі XML
4. Підключення зовнішніх XML-даних
5. Генерація XML-даних для доступу ззовні
6. Як все це працює?
7. Що це нам дає?
8. недоліки підходу
9. висновок

Останнім часом я періодично читаю курси, присвячені технології XSLT і її використання в якості мови шаблонізатора UMI.CMS. І я завжди починаю знайомство з XSLT з того, що формулюю основну ідею, винесену в заголовок цієї статті: ми працюємо з сайтом на UMI.CMS як з набором XML-сервісів.

В цій ідеї міститься вся суть підходу до розробки сайту на UMI.CMS за допомогою XSLT-шаблонізатора. Шаблонизатор в цьому випадку є інструментом для агрегації і для виведення в необхідному нам вигляді даних, що надходять в форматі XML, а XSLT - мова, за допомогою якого ми управляємо оформленням виведення. У цій статті я хотів би розповісти про особливості цього підходу для розробника сайтів, в тому вигляді, в якому це реалізовано в UMI.CMS.

Наступні можливості UMI.CMS лежать в основі реалізації цього підходу:

• Використання формату XML для представлення будь-яких даних системи
• Використання системи REST-протоколів для доступу до XML-поданням будь-яких даних (як внутрішніх даних системи, так і зовнішніх)
• При такому підході розробник використовує уніфікований механізм отримання будь-яких даних у вигляді XML, як з системи, так і ззовні. Свого роду універсальний конструктор, в якому кожну деталь, необхідну для створення сторінок сайту, ми або просимо взяти з «коробки, яка поруч» (система), або просимо принести з «складу» (WWW).

Розглянемо окремо кожну «деталь» цього конструктора.

Об'єкти системи в форматі XML

Основною особливістю UMI.CMS є те, що всі дані зберігаються у вигляді об'єктів. Всі звичні поняття в системах управління контенту, такі як: сторінки, користувачі, банери, замовлення, знижки, адреси доставки товарів, самі товари - все це об'єкти в UMI.CMS. При цьому структура об'єктів визначається універсальним чином за допомогою поняття «типи даних». Типи даних - це шаблони для створення об'єктів, які визначають кількість і тип «полів», в яких об'єкти, створені за цими шаблонами, можуть зберігати інформацію.
Ця архітектурна особливість забезпечує однаковість подання всіх сутностей системи, яке при використанні формату XML стає ще й надзвичайно наочним.

Структуру даних і самі дані для будь-якого об'єкта системи розробник може подивитися безпосередньо у вікні браузера, зробивши запит по протоколу UObject. Більше не потрібно заглядати в базу даних безпосередньо.
Для сторінок сайту, які є особливими об'єктами з прив'язкою до структури сайту, реалізована додаткова надбудова, однак, вони також є об'єктами, які зберігають дані. Структуру даних і самі дані для будь-якої сторінки розробник також може подивитися безпосередньо у вікні браузера, зробивши запит по протоколу UPage.

Результати роботи макросів в форматі XML

Бізнес-логіка UMI.CMS реалізується за допомогою API і макросів, які, по суті своїй, є методами модулів UMI.CMS. Макросів в UMI.CMS досить багато. Крім того, будь-який розробник завжди може дописати свій власний макрос або навіть цілий модуль.
Типовими ситуаціями використання макросів є: побудова меню сайту, стрічки новин, списку об'єктів каталогу, форми зворотного зв'язку і багато іншого.
Точно так же, як з об'єктами і сторінками системи, структуру даних і самі дані, які повертають макроси системи, розробник може подивитися безпосередньо у вікні браузера, зробивши запит по протоколу UData.

Вибірки з бази даних в форматі XML

Іноді перед розробником може стояти завдання по отримання деякого списку об'єктів (або сторінок) по якомусь заданому критерію. Це може бути будь-яке властивість, задана користувачем або адміністратором сайту спеціально (наприклад, «показувати на головній»), або це може бути будь-яке інше властивість (наприклад, дата публікації). Деякі подібні можливості вже можуть бути реалізовані у вигляді макросів, проте бувають ситуації, коли стандартного функціоналу не вистачає. У цій ситуації можна або створити власний макрос, або скористатися ще одним протоколом, що дозволяє отримати вибірку з бази даних - протоколом USel.
Особливістю використання цього протоколу є те, що для формування вибірки використовуються спеціальні шаблони в форматі XML, що описують результати, які ми хочемо отримати. Ці шаблони запитів також можуть приймати параметри, що дозволяє використовувати їх досить гнучко.
Точно так же, структуру даних і самі дані, які повертають запити до бази даних системи, розробник може подивитися безпосередньо у вікні браузера, зробивши запит по протколу USel.

Підключення зовнішніх XML-даних

Підхід до сайту як до набору XML-сервісів гарантує те, що ми можемо отримати будь-які дані з системи у вигляді XML. Як вже говорилося вище, за допомогою шаблонізатора ми можемо зібрати ці дані належним чином, оформити їх як це необхідно і вивести на сторінку сайту.
Однак з точки зору шаблонізатора неважливо, звідки надходять ці дані: запит відбувається за протоколами, тобто, по суті, дані і так приходять ззовні. Тому логічно припустити, що можна точно так же підключити дані з будь-яких зовнішніх XML-джерел, таких як сторонні RSS-стрічки, курси валют, пошукові результати, інші сайти на UMI.CMS і так далі.

Ці та інші результати з зовнішніх джерел можна отримати за протоколом UHttp.

Генерація XML-даних для доступу ззовні

Іноді може виникнути необхідність згенерувати і віддати дані в форматі XML назовні. Наприклад, це може бути необхідно при підключенні плагінів з використанням Ajax або Adobe Flash, для створення нестандартної RSS-стрічки, генерації Google sitemap або ще для якихось цілей.

Для цих завдань існує можливість призначити альтернативну адресацію - деякі сторінки сайту (або набір сторінок, об'єднаний з якого-небудь критерію), будуть віддавати XML-дані, сформовані на підставі шаблонів, створених розробником. У ці шаблони він може включити будь-які дані з усіх вищеописаних протоколів, перетворити їх так, як це йому необхідно і віддати назовні саме в тому вигляді, в якому потрібно.

Як все це працює?

Справа в тому, що в той момент, коли запитується сторінка з браузера, система також генерує XML-документ. Цей XML-документ містить всі дані про відкривається сторінці (поля і зберігається в них інформацію), а також додаткові відомості про становище в ієрархії сайту, користувачі, що відкривав цю сторінку і деякі інші відомості.

Для того, щоб віддати HTML-код в браузер і показати сторінку користувачу, до цього XML-документу застосовується XSL-шаблон, який і визначає те, як повинен виглядати HTML-код, побудований з урахуванням даних з вихідного XML-документа.
Цей XML-документ також можна подивитися безпосередньо в браузері, додавши до адреси сторінки ".xml". Тобто розробник завжди може дізнатися точно, до чого саме застосовується шаблон.

Однак інформація, що зберігається в запитаної сторінці, відноситься тільки до цієї сторінки: наприклад, її контент, заголовок або опис. Ця сторінка «нічого не знає» про те, чи повинна в підсумку виводитися на ній меню, стрічка новин, блок з товарами або щось інше. Для того, щоб вивести ці дані, ми повинні отримати їх у системи, запросивши додаткові XML-документи - такі як, наприклад, результати роботи макросів, вибірки з бази даних, властивості інших сторінок і все що можна отримати за протоколами системи.

Малюнок 1: сторінка сайту на UMI.CMS
Щоб підключати ці XML-дані для виведення їх в HTML-код, використовуються всі ті ж XSL-шаблони для сторінок сайту. У шаблонах використовується всього одна функція XSLT - функція document (), якою розробник вказує XML-ресурси, розташовані за адресою імя_протокола: // набор_параметров. наприклад:

• uobject: // 14 - запит поверне XML-представлення об'єкта системи з id = 14
• upage: // 7 - запит поверне XML-представлення сторінки сайту з id = 7
• udata: // content / menu - запит поверне XML-представлення меню сайту
• usel: // special-offers /? limit = 5 - запит поверне XML-представлення вибірки з бази даних системи за критеріями, описаним в файлі special-offers.xml з параметром limit = 5
• uhttp: // www.cbr.ru/scripts/XML_daily.asp - запит поверне зовнішній ресурс зі списком курсів валют

Таким чином, на будь-якій сторінці сайту можна виводити не тільки її контент або інші її властивості, а будь-які дані, які можуть бути отримані за протоколами. Розробник в шаблонах сам визначає, що саме буде на певних сторінках сайту, в відповідно до власних потреб.

Що це нам дає?

Щоб правильно написати XSLT-шаблони, розробник може викликати у вікні браузера вихідні дані, не звертаючись в документацію, працюючи безпосередньо з тією інформацією, яку він хоче обробляти в шаблонах. Наприклад, щоб подивитися результат, який поверне макрос, що виводить меню, досить набрати в адресному рядку: http: // адрес_сайта / udata / content / menu
І розробник побачить xml-уявлення для меню сайту у вигляді списку сторінок з ідентифікаторами, назвою і реальним порядком, визначеним структурою сайту:

<Udata module = "content" method = "menu" generation-time = "0.006117">
<Items>
<Item id = "1" link = "/" xlink: href = "upage: // 1"> Ласкаво просимо </ item>
<Item id = "2" link = "/ talks /" xlink: href = "upage: // 2"> Форум </ item>
<Item id = "12" link = "/ vse_novosti /" xlink: href = "upage: // 12"> Всі новини </ item>
<Item id = "33" link = "/ butterfly /" xlink: href = "upage: // 33"> Фотогалерея </ item>
<Item id = "43" link = "/ market /" xlink: href = "upage: // 43" status = "active"> Каталог товарів </ item>
</ Items>
</ Udata>

Таким чином, написання шаблонів не представляє складності і практично виключає необхідність налагодження.
Грамотне використання цього підходу дозволяє дуже швидко накопичити набір готових рішень (для оформлення окремих блоків на сторінках сайту або навіть для цілих сторінок цілком), які в подальшому можна використовувати з проекту в проект, лише змінюючи стилі CSS і основні шаблони зовнішнього вигляду сторінок.

недоліки підходу

Одним з недоліків цього підходу можна назвати необхідність здійснювати додаткові запити, що може віднімати ресурси і збільшувати час, необхідне для генерації сторінок. Це може бути особливо актуально, якщо звертатися до зовнішніх даних, а не до даних з системи.
Саме для таких випадків в UMI.CMS додана можливість використовувати кешування для запитів по протоколам. У цій ситуації система не буде здійснювати реальних викликів, а буде брати дані з кеша практично миттєво, значно заощаджуючи використання ресурсів.
Другим недоліком можна назвати реальний «спокуса» спробувати втілити бізнес-логіку безпосередньо в шаблонах. У цій ситуації, швидше за все, результатом буде втрата продуктивності, масштабованості і можливості повторного використання шаблонів в інших проектах. На щастя, мова XSLT не цілком підходить для подібного використання і закономірні труднощі, що виникають на цьому шляху, зазвичай допомагають зрозуміти, що відбувається щось не те.

висновок

Реалізація підходу до сайту як набору XML-сервісів в UMI.CMS використовує універсальний спосіб представлення, отримання даних і виведення їх на підсумкову сторінку сайту. Крім того, розробнику надана можливість в будь-який момент отримати наочне уявлення тих даних, з якими він працює.
Розширюючи стандартний функціонал системи за допомогою призначених для користувача макроси і використовуючи шаблонизатор для агрегації і виведення інформації, розробник отримує в своє розпорядження практично нічим не обмежену свободу в управлінні як логікою системи, так і висновком даних.