Вы когда-нибудь слышали сочетание букв SDL? А как насчет SDL Tridion или SDL Web? Нет? Неужели. Тогда давайте я расскажу немного о том, что это и почему это так больно.

Название и версионирование

Тут все сильно не однозначно. Я не буду говорить про сильно старые версии, но в 2011 эта CMS называлась SDL Tridion и имела версию 2011, что как бы логично. В 2013 эта CMS стала SDL Tridion 2013. Уже в 2015 году название резко сменилось и CMS стала называться SDL Web с версией 8! После вышло обновление SDL Web 8.5. Последняя версия на 2019 год — 9. Последнее название, не удивляйтесь, SDL Tridion Sites.

Что это за зверь?

SDL XXXXXX (далее просто SDL) представляет из себя CMS для статического контента с «удобной» поддержкой локализации. Если вы международная компания и вам нужен сайт, то SDL, вроде как, должен решить все ваши проблемы. Единственная оговорочка, не старайтесь сделать сайт сложнее визитки или обычного каталога. Только статика, или хардкор.

По большому счету SDL представляет из себя 2 макросервиса. На одном вы храните и редактируете контент. На второй вы его публикуете и он становится доступным в сети. Я сильно упрощаю устройство, если кому интересно, можно полезть и почитать документацию.

Первый макросервис называют Content Manager (далее CM). Его интерфейс смахивает на программу для Windows 98 как внешне, так и по скорости отклика. Картинки из интерфейса вы также можете найти в документации. Сам контент менеджер состоит из сущностей, одной из главных, которая является публикация. Публикация это некая папка, внутри которой можно создавать разный контент. «Киллер фичей» CMS является то, что публикации могут наследоваться друг от друга. Этот механизм они называют BluePrint Hierarchy. Унаследованная публикация получает весь контент от публикации предка. Такой контент называется shared. В публикации наследнике можно создать новый контент, либо же локализовать расшаренный контент с целью внести правки и изменения. Поддерживается множественное наследование. Проблему ромбовидного наследования решили заданием приоритетов предкам.

Что находится в публикациях

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

Folders
|
|_Schemas/Components/Templates
|
Structure groups
|
|_Pages
|
Categories
|
|_Keywords

Для чего нужны папки, думаю, объяснять не надо. Поэтому перейдем к следующему пункту. Схемы это описание данных. В какой-то степени это аналог классов в ООП языках. Компоненты это объекты тех самых классов. А вот темплейты это то, как эти данные отображать. Темплейты есть как для компонентов, так и для пейджей (о них чуть ниже).

Следующий пункт это структурные группы. По сути являются такими же папками, но внутри могут хранить либо другие структурные группы, либо страницы. По вложенности структурных групп будет формироваться URL нашей страницы в будущем.

Страницы представляют из себя набор Component Presentation-ов, которые в свою очередь являются парой компонент + темплейт. Для того, чтобы компонент и его темплейт можно было связать, нужно чтобы и тот и другой были основаны на одной и той же схеме. В будущем именно код, написанный в компонент темплейтах будет забирать данные из компонентов и превращать эту связку в html, либо во что либо другое.

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

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

Страх и ненависть к SDL-у

Если вас когда-либо пригласят работать туда, где есть эти три буквы, то советую вам либо бежать, либо же арендовать кабриолет и забить багажник всякими вредностями, как в кино.

Итак вы сели в кабриолет. Добро пожаловать в e-commerce. Тут вам придется отбиваться мухобойкой от летучих мышей, выкуривать сигареты одна за другой и есть вкусности почти всегда, чтобы хоть как-то понимать, что происходит вокруг да около.

Полное отсутствие документации. Ни слова. Тсс. Даже не пытайтесь искать. Берешь API. Дергаешь. Смотришь результат. А результат, как правило, не всегда очевиден, точнее, всегда не очевиден. Все сделано максимально по своему и максимально через одно место, чтобы купившие лицензию никогда в жизни даже не попытались поискать альтернативу.

Немного конкретики

У великого Content Manager (CM) есть свой API. Называется эта штука CoreService. Генерируется она достаточно просто из wsdl. Далее вы можете использовать методы, предоставляемые этим сервисом, чтобы достучаться до того или иного элемента внутри CM, как либо его изменить или произвести над ним любые действия, доступные из устаревшего веб интерфейса. При большом желании можно написать свой UI, но come on, кому это надо.

Так вот, если вы попытаетесь загуглить хоть какое-то подобие документации в гугле, они вычислят вас по ip у вас не получится. Даже не пытайтесь.

Вы можете постараться понять все по названиям методов и параметрам. Это сложно, но задача вполне себе выполнимая. И тут вы увидете кучу непонятных объектов.

Приведу лишь некоторые примеры.

public class ArrayOfTcmUri {

    @XmlElement(name = "TcmUri", nillable = true)
    protected List<String> tcmUri;

    public List<String> getTcmUri() {
        if (tcmUri == null) {
            tcmUri = new ArrayList<String>();
        }
        return this.tcmUri;
    }

И такого добра просто валом. Столь прямой код торчит ото всюду. И вам так или иначе придется с ним работать.

Кроме неудобного API вы также столкнетесь с постоянными проблемами с подключением. Вам также придется дописать обертку над CoreService, которая при разных ошибках, связанных с подключением будет через некоторое время пытаться повторить запрос. А еще вы столкнетесь с кучей совершенно непонятных exception-ов. Иногда по вине ошибочных данных, иногда из-за каких-либо ошибок на стороне сервера. Также, CoreService оставляет за собой право вернуть вам неправильные данные, причем произойти это может в любой момент. Хватает лишь немного нагрузить его.

Перед нашей командной стояла задача изменить модель данных. Задача должна была свестись к банальному вычитыванию всех данных, применению преобразований и заливки обратно.
Количество боли, в попытках так или иначе изменить модель данных не сравниться ни с чем.

Пример номер раз.

Вы вычитываете какую-либо схему, которая хранит в себе описание данных, как я говорил выше, некое подобие классов в ООП. Все поля (fields) этой схемы, которые красиво и удобно описываются через веб интерфейс, в итоге хранятся в XML формате. Формат очень сложный и изменять его это самая настоящая боль. На бой бросаются все инструменты, от XPATH-а до Regexp-ов, и даже String::replaceAll.

А в один прекрасный день, копаясь в исходниках CoreService-а ты находишь несколько странных методов, из названия которых вроде бы вырисовывается то, что можно из XML получить список всех полей и наоборот. Конечно же, каждый раз придется обращаться к CM. Ты впадаешь в ярость, но в тоже время радуешься, что все написанные до этого костыли можно будет привести в более аккуратный, читаемый и поддерживаемый вид.

Пример номер два.

Представьте себе схему, в которой одно из полей имеет тип другой схемы. Что-то вроде:

class A {
   class B;
   int a;
}

И вот вы читаете ее через CoreService и получаете какой-то странный XML. В нем явно много лишнего. Вы заходите на веб интерфейс, но там с XML-ом все в порядке. А в ваш XML почему-то вместо поля типа ссылки на другую схему пришла схема, внутри которой находится эта вторая схема. Как? Почему? Что делать? Увы, мы так и не нашли решение…

Пример номер три.

Вы решили изменить название какого-либо поля схемы. Так как вы теперь имеете удобный API для работы с полями, все должно пройти гладко. Итак, вы считываете схему, меняете название поля, сохраняете схему и… О, чудо! Все прошло гладко. Вы в этот день со спокойной душой ложитесь спать, и вам сняться розовые единороги в кузове красных БЕЛАЗ-ов, а на следующее утро команда обнаруживает, что у всех компонентов, базирующихся на той вчерашней схеме пропало поле. Его больше нет. И данных тоже, теперь уже, увы, нет… Даже такая легкая, казалось бы, операция, как переименование филда, влечет за собой огромное количество работ.

Пример номер 100500

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

Вместо итога

Проведя с LSDL 6 месяцев, я понял, что создатели этой CMS очень любят трудных детей. Ведь только употребляя кислое трудное дитя Альберта Хоффмана можно как-то сохранять баланс и что-либо понимать в этой максимально неповоротливой, полностью закрытой и абсолютно бесполезной CMS. Так что, если вдруг вы увидите этот классный кабриолет с забитым багажником, который так и манит прокатиться, задумайтесь, а может свой велосипед тише едет, но все таки будет дальше?