Моделі контенту в Alfresco

Тут уже написано кілька постів про Alfresco з технічного боку. І про те, як працювати з Workflow, і про те, як створювати свої java-класи, але чомусь втрачені самі основи. Хочеться виправити цей недогляд та описати структуру зберігання та подання контенту в Alfresco. Найбільш основи. Це і пояснює структуру деяких XML в минулих постах, і описує, як вирішити деякі завдання на Alfresco. Приступимо.

Яке завдання є основним для Alfresco? Зберігання структурованих даних. Alfresco – це сховище інформації. А також засіб роботи із цією інформацією. Але все це живе лише "навколо" самих даних.

Як же ці дані в Alfresco зберігаються?

Якщо документи будуть просто документами, без будь-якої додаткової інформації, то ними буде складно орієнтуватися. Наприклад, про текстовий документ, доки ви його не відкриєте, ви не знатимете нічого, крім факту його існування. Для нормального, структурованого зберігання документів потрібні метадані, що характеризують дані, що зберігаються. За замовчуванням, до них заносяться такі речі, як дата і час створення та останньої зміни даних, власник файлу, тип файлу та інші аналогічні речі.

Те, які метадані є у файлу, залежить від моделі контенту. Також як розширення файлу описує тип вмісту, модель контенту описує тип контенту.

Якщо говорити більш загально, моделі контенту описують дані, що зберігаються в репозиторії. Без моделей Alfresco вміла б не більше файлової системи. Подивимося, що саме додають моделі контенту до функціонала Alfresco:

Фундаментальні типи даних і те, як ці типи повинні зберігатися в базі даних. Наприклад, без моделей контенту, Alfresco не знала[1] різницю між типом String і Date.
Високорівневі типи, такі як "content" і "folder", є такими ж моделями, як і моделі власної розробки "Звіт" або "Контракт".
Деякі аспекти, які працюють з коробки, такі як “auditable” та “classifiable”, є частиною моделі, так само як і “rateable” або “commentable”.
Властивості (вони метадані) специфічні для кожного типу контенту.
Обмеження, що застосовуються до властивостей (наприклад, за регулярним виразом, за довжиною або взагалі вибір точної властивості зі списку можливих).
Індексування контенту для пошуку.
Взаємини між різними типами контенту.

Розглянемо з прикладу, як створюються нові моделі. Допустимо, ми будемо використовувати Alfresco для зберігання документів-заявок, що надходять сюди за підсумками запитів користувачів. Вони повинні мати номер, тип, важливість та інші властивості. Для того щоб ці властивості з'явилися, потрібно створити нову модель даних. Це робиться створенням нового файлу в папці tomcat/shared/classes/afresco/extension/. Назвемо нашу модель "Запит". У такому разі створимо файл request.xml. А тепер перейдемо до його вмісту:

Оголошення нової моделі, імпортування існуючих моделей та простір імен:

Типи схожі класи об'єктів в ООП. Прикладами стандартних типів Alfresco служать "Content", "Person" і "Folder". Створювані Вами власні типи обмежені лише вашою фантазією та вимогами бізнесу. Наприклад, "Звіт про прибутки", "Медичний запис", "Фільм", "Пісня", "Коментар".

У рамках "Запиту" створимо тип "Заявка". Цей тип повинен мати деякі властивості та асоціації. Але про це трохи згодом. Спочатку сам тип:

Властивість - це складова частина метаданих, асоційованих із цим типом. Наприклад, властивостями"Звіти про збитки" можуть бути такі властивості як: "Ім'я працівника", "Дата створення", "Проект", "Клієнт" і т.д. Цей тип може мати властивість "дані" для зберігання файлу зі звітом у форматі Excel або PDF. У нашому випадку властивостями будуть "Номер", "Категорія", "Статус".

Асоціації

Асоціації визначають відносини між типами. Без асоціацій, модель може бути сповнена типами, які посилаються на інші частини даних. Повертаючись наприклад з "Звітом з прибутку" ми можемо зберегти кожен рядок як окремий об'єкт. До типу "Звіт про прибуток" ми можемо додати тип "рядок звіту". Використовуючи асоціацію, ми можемо сказати Alfresco про відносини між цими типами. Асоціації бувають двох типів: "рівні асоціації" та й асоціації "підпорядкування". "Рівні" асоціації визначають відносини між двома об'єктами, але не підкоряють їх один одному. "Підлеглі" асоціації навпаки використовуються для того, щоб показати таке підпорядкування. Наведений вище приклад є прикладом "підлеглих" асоціацій. Інший приклад - "Звіт" та "Документи додатку" - вони будуть пов'язані "рівними" асоціаціями.

Обмеження

Обмеження використовуються визначення того, які дані можуть зберігатися як тип. Існують чотири типи обмежень: REGEX, LIST, MINMAX, і LENGTH.

REGEX використовується для обмеження властивості за допомогою регулярних виразів
LIST використовується для визначення списку можливих значень
MINMAX для обмеження цифрових значень
LENGTH для визначення довжини якості

Обмеження можуть бути визначені один раз та використовуватися у всіх моделях Alfresco. Наприклад, скрізь можна використовувати обмеження "cm:filename" для REGEX-обмеження на ім'я файлу.

У розглянутій вище властивості"Статус" ми вже вказали, що використовуватимемо певне обмеження на допустиме значення поля статусу заявки. Напишемо тепер реалізацію цього обмеження:

Перед тим як говорити про аспекти, давайте зрозуміємо, як працює успадкування. Допустимо ми використовуємо Alfresco для керування даними та відображення їх на сторінці порталу. Припустимо, що ми хочемо бачити лише частину даних. Простий приклад це відображення дати та часу надсилання даних на портал. Використовуючи модель даних, ми можемо надійти двома способами: перший - це визначити таку властивість у кореневому типі для всіх об'єктів, і всі об'єкти-спадкоємці будуть його успадковувати від кореневого типу. А другий спосіб – визначити цю властивість тільки для тих типів, які відображатимуться на порталі. Природно другий спосіб кращий, а перший легший. Якщо ми підемо першим шляхом, то Alfresco буде працювати повільніше, і, якщо ми зробимо два-три такі глобальні властивості, ми можемо вже не сподіватися на отримання нормальної продуктивності системи. Якщо ми підемо другим шляхом, то ми прийдемо до аспектів.

Допустимо, ми хочемо підключити до своєї моделі даних аспект "Складність" для заявки. Подивимося, як це виглядатиме:

Усередині аспектів ми не зустрічаємо нічого нового. Просто уявіть, що це просто зовнішній тип.

Підведемо підсумок

Alfresco вибаглива до послідовності блоків, розглянутих вище в хаотичному порядку. Збираючи їх у єдиний xml-файл потрібно дотримуватися наступного порядку:

Олег Китаков

okitakov [AT] gmail [DOT] com