Alfresco - лучшие практики для жизненного цикла пользовательских документов (Java?) - PullRequest
1 голос
/ 22 ноября 2011

Поговорив с некоторыми людьми в DevCon в Лондоне и посмотрев исходный код Records Management, я заметил, что на самом деле нет хорошего примера реализации жизненного цикла пользовательских документов.Я знаю, что есть примеры правил, моделирования контента и даже рабочих процессов, но эти решения нельзя реально использовать для реализации чего-то более серьезного, например, управления записями.

Что мне интересно, так это как эффективно отобразить решение Java (У меня больше опыта работы с OO и Java, чем с Alfresco) до Alfresco.Что должно быть определено как класс Java и что должно быть типом / аспектом в модели содержимого.Когда следует отдавать предпочтение поведению по сравнению с правилами, а когда фактически использовать рабочие процессы.В моих первых нескольких проектах я использовал рабочие процессы для реализации жизненного цикла документа, я написал довольно много бизнес / логики домена в узлах рабочего процесса - как действия (JS).Позже я узнал, что это довольно сложно поддерживать, поскольку у вас есть некоторый код в рабочих процессах, некоторый в хранилище в виде скриптов (словарь данных / скрипты), некоторый Java, ...

Является ли хорошим примером для начала Управление записямиучитесь и видите некоторые лучшие практики в реализации полного жизненного цикла документа?Есть ли какие-либо другие ресурсы?

Больше всего я борюсь с тем, как реализовать полный жизненный цикл в Java и как "централизовать" бизнес-логику / доменную логику.

1 Ответ

5 голосов
/ 22 ноября 2011

Область применения ECM огромна, и поэтому довольно сложно придумать полностью общие рекомендации: вам действительно нужно придерживаться сценария использования, к которому вы должны обратиться, и найти для него наилучшее решение. RM является отличным примером того, как реализовать решение для управления записями поверх Alfresco, но абсолютно бесполезно, когда речь идет о реализации процесса веб-публикации, для которого WCM QS то, что вы хотите посмотреть в качестве отправной точки.

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

Типы содержимого

Здесь всегда нужно начинать реализацию проекта Alfresco. Вам необходимо тесно сотрудничать с кем-то, обладающим глубокими знаниями предметной области обработанного документа, который необходимо реализовать, и определить корневые элементы для различных жизненных циклов документов. В Alfresco вы должны назначить один и только один тип контента для данного узла. Это делается во время создания контента и не часто изменяется в течение жизненного цикла контента. Таким образом, типы контента обычно используются для идентификации элементов контента с радикально различными жизненными циклами (например, cm:document и ws:article), а определение типа контента означает извлечение основных свойств метаданных, которые будут использоваться или использоваться в течение всего жизненного цикла документа. .

Аспекты

Хотя типы контента в основном представляют собой статическую вертикальную классификацию и обогащение документов, аспектами являются их динамические родственники. В отличие от типов контента, вы можете применять или удалять аспекты динамически с минимальными разрушительными последствиями для узлов контента. Они могут обогащать документ дополнительными метаданными или нет, и могут применяться к элементам независимо от их типов содержимого. Эти характеристики делают аспекты, возможно, наиболее гибкой функцией модели содержимого Alfresco: их можно использовать для маркировки содержимого или включения / отключения операций, совместно используемых различными жизненными циклами содержимого (например, cm:versionable, rma:filePlanComponent). По своей природе аспекты предназначены для обработки сквозных концепций, которые встречаются в нескольких различных жизненных циклах или этапах жизненного цикла.

Поведения

Здесь мы начнем обзор того, как добавить логику в ваше решение Alfresco. Поведения - это автоматические вычисления, которые запускаются определенными триггерами, где триггеры определяются как пара [тип / аспект, политика] (например, [cm:versionable, onCreateNode]). Как правило, они выполняются в рамках одной и той же транзакции события, которое запускает триггер, нет гарантии порядка выполнения и нет координации или оркестровки. Это делает их идеальными для автоматической генерации или обработки контента (например, создания эскиза или обновления некоторых метаданных), которые должны быть неотъемлемой частью жизненного цикла контента, но не являются строго частью формализованного процесса.

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

Правила

Подобно поведению, правила запускаются при определенных событиях, но они гораздо более общие и динамичные, чем они. Вы можете настроить правила только для папок во время выполнения и связать их с событиями, происходящими в папке. Это делает их идеальными для создания специальных блоков в вашем хранилище контента (например, отправка электронного письма всякий раз, когда контент добавляется в определенную папку), где возникают побочные эффекты, когда вы имеете дело с контентом внутри него. Они реализованы как скрытые узлы внутри папок, что является неотъемлемой частью экспорта: теоретически вы можете заимствовать их в разных реализациях Alfresco, если доступны необходимые фрагменты.

Они обычно используются, когда часть логики применяется к контенту нескольких различных типов, но, возможно, не ко всем элементам затронутых типов, и только когда вы можете хранить все затронутые узлы контента в подветви хранилища. Даже если такое ограничение может показаться тяжелым, правила оказываются весьма удобным инструментом (например, создать миниатюру для всех документов png с типом mime image/png в /images).

Действия

Действия - это связанные логические элементы, которые могут быть вызваны для узла по требованию. Они являются строительными блоками для правил и часто используются в рабочих процессах (например, отправляют электронное письмо). Они также удобны для непосредственного связывания с компонентами / кнопками пользовательского интерфейса, чтобы позволить пользователю быть непосредственно связанным с доступными функциями вашего приложения. Обычно вы заканчиваете тем, что разрабатываете действие, когда вам необходимо (или хотите включить) повторное использование одного и того же логического элемента в разных контекстах, таких как рабочий процесс, правило и / или прямое взаимодействие с пользователем.

* 1051 рабочих процессов *

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...