К сожалению для программиста, после окончания разработки проекта на Umi.CMS у него могут возникнуть две проблемы:
1) Как объяснить человеку, ответственному за наполнение контента, устройство проекта.
2) Как в период гарантийного обслуживания оперативно решать проблемы с работой проекта.
Umi.CMS предоставляет набор модулей, достаточно абстрагированных от решения реальных задач. Собственно, ни один из имеющихся в системе модулей
не позволяет сразу решать задачи заказчика, так как заложенный в шаблонах по умолчанию функционал достаточно ограничен. Вместо готового решения конкретных задач
предлагается набор инструментов, позволяющий гибко готовить нужные решения.
Подобная гибкость имеет обратной стороной высокую зависимость от уровня подготовки и особенностей отдельного программиста.
Задачи можно решать разными способами, а способ может быть настолько нетривиален, что создаст реальные проблемы для всех, кто его использует.
Человек, наполняющий контент, будь то профессиональный копирайтер или неведомый исполнитель заказчика, хочет решать только свои задачи, а вместо этого ему
приходится долго адаптироваться к особенностям конкретной реализации проекта. Недостаточная квалификация программиста либо сложный проект, требующий нестандартного подхода,
приводят к тому, что в административной панели Umi.CMS вырастает развесистое дерево взаимосвязанных страниц разных типов данных с многочисленными параметрами.
Заблудиться в таком дереве очень легко, даже подготовленная для копирайтера документация не может застраховать от случайностей. Возникает вопрос оптимизации дерева до такой степени, чтобы даже в случае возникновения серьезных ошибок
оставалась возможность восстановления работоспособности сайта. И желательно только средствами административной панели, без вмешательства в код шаблонов и макросов.
Ударный рост дерева страниц вызывается следующими причинами:
1) Большое количество зарегистрированных в системе шаблонов. Например, в настройках модуля «Структура» регистрируются шаблоны на все случаи жизни: для главной страницы, для новостей, опросов, форума и т.д.
Помимо шаблонов с очевидным предназначением могут быть зарегистрированы специализированые шаблоны вида «Особая акция нашей фирмы такая-то» или «Форма отчета №22».
При создании новой страницы копирайтер вынужден выбирать шаблон из большого списка, что неприятно само по себе и может вызывать определенные сложности, если назначение шаблона непонятно.
Как правило, множество шаблонов регистрируется при использовании TPL-шаблонизатора Umi, однако некоторые проекты обладают настолько эклектичным дизайном, что даже применяя XSLT-шаблонизатор,
регистрируют дополнительные шаблоны. Хотя использование XSLT-шаблонизатора по крайней мере позволяет создавать действительно разные шаблоны.
2) Большое количество параметров, создаваемых для отдельных типов данных. Например, помимо специальных страниц с параметрами для отображения каталога либо интернет-магазина могут создаваться группы параметров для отображения конкретного раздела каталога.
Усугубить проблему может желание программиста сократить время разработки и привязать выборку параметров из особо важных страниц к идентификаторам этих страниц.
Часто создается страница вида «Жизненно необходимые параметры интернет-магазина» с определеным идентификатором. Чтобы получить доступ к свойствам этой страницы, программист
прямо в шаблоне прописывает этот идентификатор. Копирайтер или, что, как ни странно, бывает чаще, неведомый исполнитель заказчика случайно удаляет эту страницу. Интернет-магазин ломается и простое создание страницы такого же типа данных в административной панели
не спасает ситуацию, так как её идентификатор не совпадает с прописанным в шаблонах. Приходится привлекать программиста, анализировать шаблоны и будет хорошо, если таких шаблонов мало.
3) Тесная взаимосвязь страниц дерева, применяемая для реализации некоторой функциональности проекта.
Допустим, есть задача вывести галерею фотографий определенного товара, причем количество фотографий может быть любым. Реализовать это можно следующим образом.
Создается галерея изображений и в дереве страниц вкладывается в страницу товара, становясь его дочерней страницей. В шаблоне выполняется поиск дочерней галереи и вывод её на страницу. Для копирайтера всё достаточно просто. Галерею ему все равно придется создавать, а её назначение товару происходит методом перемещения по дереву в нужное место.
Однако в случае, если галерея не перемещена в нужный товар, ничего не выведется, так как шаблон товара не найдет её.
Если же задать товару свойство «Ссылка на дерево» и указать в нем конкретную галерею, то её перемещение никак не отобразится на отображении фотографий, но копирайтеру придется добавлять лишнее свойство.
Любой из этих вариантов решает конечную задачу, но имеет свои недостатки.
Понимая, что ошибки наполнения контента могут существенно усложнить жизнь программиста, программисту лучше заранее попытаться оптимизировать дерево страниц, насколько это возможно в условиях конкретного проекта.
И делать это нужно сразу на этапе подготовки системы для работы.
1) Если есть возможность, лучше всё-таки использовать XSLT-шаблонизатор, поскольку в нём есть возможность относительно просто сократить количество регистрируемых в системе шаблонов. Это избавит копирайтера от необходимости делать сложный выбор,
а программиста от необходимости искать и устранять ошибки, вызванные назначением неверного шаблона. Можно, конечно, реализовать вывод различного функционала и в пределах одного TPL-шаблона, однако потребуется масса усилий по написанию кастомных макросов и JavaScript-кода. Несмотря на работоспособность такого подхода
сроки и сложность разработки возрастают значительно.
2) Поскольку работа программиста в Umi.CMS сводится к созданию новых типов данных, а также свойств для новых и имеющихся типов данных, желательно заранее выполнить всю необходимую работу в модуле «Шаблоны данных».
Особенно следует уделить внимание созданию типов данных страниц параметров. Если в проекте предполагается использовать определенные параметры, их желательно не размещать в множестве разных страниц, а содать отдельный тип данных с нужными группами свойств.
Сами страницы такого рода желательно группировать в одном месте, чтобы снизить вероятность их случайного удаления. Можно создать для этих страниц отдельную родительскую страницу.
Особый тип данных полезен тем, что выборку параметров можно не привязывать к идентификатору страниц. Вместо этого можно выполнить Usel-запрос на поиск страницы с параметрами.
Например, у нас есть страница параметров интернет-магазина. Нам нужен идентификатор не самой страницы, а её типа данных, например 152. Создадим Usel-запрос getSpecial.xml вида
<?xml version="1.0" encoding="UTF-8"?>
<selection>
<target expected-result="pages count" force-hierarchy="1">
<type id="{1}" />
<category depth="{3}">{2}</category>
</target>
<limit page="{p}">{6}</limit>
<sort order="{4}">{5}</sort>
</selection>
Тогда запрос вида usel://getSpecial/152/0/0/ascending/id/1/ вернет нам первую страницу такого типа данных. Если копирайтер случайно удалит эту страницу, можно будет создать новую прямо в административной панели без вмешательства в шаблоны. Это будет особенно полезно, если
запретить копирайтеру доступ к модулю «Шаблоны данных», зарегистрировав для него отдельного пользователя с ограниченными правами.
В шаблонах проекта желательно вообще не использовать никаких идентификаторов страниц. Поиск многих страниц можно организовать по их типу данных либо по особым свойствам с помощью протокола Usel.
Чтобы сократить упоминание в шаблонах не только идентификаторы страниц, но и идентификаторы типов данных, можно активно использовать переменные. Например,
<xsl:variable name="commonParamsId" select="document('usel://getSpecial/152/0/0/ascending/id/1/')/udata/page[1]/@id" />
<xsl:variable name="commonParams" select="document(concat('upage://', $commonParamsId))/udata" />Использование последней переменной далее в шаблоне избавляет от необходимости применять идентификатор типа данных 152. Хотя, если копирайтер доберется до шаблонов данных и удалит их, всё равно всё придется переделывать.
3) Несмотря на то, что тесная взаимосвязь страниц может вызывать определенные проблемы, с её помощью легко организовать обучение копирайтера по принципу «Делай, как здесь», создав тестовый образец данных, так как он предельно нагляден.
Вернемся к примеру с фотографиями для товара. Можно создать отдельную страницу-контейнер со списком галерей, а товару создать свойство «Ссылка на дерево» для выбора правильной галереи. Если галерея назначена, то она исправно будет отображаться на странице товара вплоть до своего удаления.
Однако, поскольку галерея лежит в отдельной ветке, её связь с товаром неочевидна. При заполнении контента придется учитывать, что товар есть где-то там, а галерея где-то здесь. К тому же выбор по «Ссылке на дерево» из большого дерева страниц может быть неудобен.
Если же галерея вложена в товар, их взаимосвязь очевидна.
Не следует недооценивать важность заботы об удобстве копирайтера во время разработки, если, конечно, вы не уверены в том, что ваш проект не вернется к вам на доработку и вам не придется объяснять
копирайтеру логику своих решений. Оптимизация дерева страниц в дополнение к документации — это один из способов снизить сложность адаптации копирайтера к проекту и снять значительную часть вопросов по его устройству.
Как следствие, программист избавляется от лишних рисков для себя на этапе технического сопровождения проекта.
Автор: angekus
