Подтвердить что ты не робот

Java-CMS с сервисом RESTful/API для доступа к контенту

Для тех, кто может проголосовать, чтобы закрыть этот вопрос из-за "не конструктивного". Как он в настоящее время стоит, этот вопрос не подходит для нашего формата Q & A ". - Было бы здорово, если бы вы предложили , где, я должен опубликовать этот вопрос (https://softwareengineering.stackexchange.com/ или любой форум, ориентированный на CMS?)

Аналогичные вопросы задавали раньше:

Все они несколько лет, поэтому мне интересно, есть ли новые рекомендации/дискуссии вокруг этого.

Некоторый фон: мы являемся магазином Java, мы создаем/поддерживаем веб-сайты для наших клиентов, наш технический стек - это Java, Spring, SQL, JSP, HTML5, JQuery, Tomcat, JBoss, Maven и т.д.... обычный материал. До сих пор в терминах "контента" мы либо помещали его в некоторый файл свойств, который читал JSP для копий (например, описание продукта X), так и внутренняя служба, предоставляющая динамический контент (например, какое текущее значение продукта X).

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

Несколько вещей, которые я особенно ищу:

  • Java-based (потому что мы являемся магазином Java: 1) больше опыта в обработке материалов на основе Java и 2) избегаем введения в стек других технологий)

  • Расширяемость/настройка. Необходимо иметь возможность настраивать CMS (именно поэтому мы хотим придерживаться нашей экспертизы Java), чтобы ее можно было расширить, чтобы подключаться к другим веб-сервисам для потребления контента и т.д.

  • Сосредоточьтесь на контенте - нам нужно четкое разделение между контентом и UI-рендером, возвращаясь к тому, что мы ищем, где нам нужно доставить контент в отдельные свойства.

  • Служба RESTful/API для доступа к контенту - такая же, как и выше. Нам нужно, чтобы контент был доступен напрямую как JSON/JSON-P/. XML-канал.

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

  • Многоязычная поддержка

  • Открытый исходный код/​​низкая стоимость

До сих пор у меня было несколько вариантов:

Adobe CQ - выглядит как самое идеальное решение, но, к сожалению, оно дорого стоит

Hippo CMS. Похоже на то, что мы ищем, я не уверен, насколько хорошо он задокументирован, учебник/инструкции выглядят довольно скудными, их доля на рынке, кажется, больше в Европа, чем в Северной Америке.

Liferay - более целенаправленно как "портал", а не CMS, предоставляющий контент

Alfresco - Больше внимания уделяется "документам"

dotCMS. Как и Hippo CMS, похоже, что это может соответствовать нашим потребностям.

Магнолия CMS. Оглядывается на ту же аллею, что и dotCMS и Hippo. Из комментариев, которые я видел, похоже, что они больше сосредоточены на одном веб-сайте, а не на чистое разделение между содержимым и UI.

У меня лично нет большого опыта работы с CMS раньше.

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

4b9b3361

Ответ 1

Лично у меня есть опыт работы с Hippo и много с dotCMS. Я немного знаю об Альфреско, Лифере и Магнолии, но я раньше с ними не работал. У меня нет опыта с Adobe CQ, потому что я никогда не занимался исследованием времени. Это связано с тем, что высокие затраты не являются для многих наших клиентов. Alfresco действительно лучшее решение, если вы ищете онлайн-систему управления документами, которая, как я думаю, вы не являетесь. Вы правы в том, что Hippo, Magnolia и dotCMS несколько похожи, что не так уж странно, потому что они пытаются решить одну и ту же проблему: быть системой Java Web Content Management System на базе Java. Они в значительной степени сосредоточены на управлении контентом, который может использоваться на страницах, которые также управляются с помощью CMS.

Если честно: у меня есть предвзятость к dotCMS, потому что я много работал с системами и много знаю об этом. Я думал, что объясню, почему это работает для нас, поэтому вы можете принять это во внимание. Я работаю в магазине Java, который делает много промежуточного программного обеспечения для своих клиентов, используя JBoss и весь стек EE. Мы соединяем старые (Cobol) и новые системы вместе и ставим блестящий новый веб-интерфейс поверх этого промежуточного программного обеспечения, предназначенного как для администраторов, так и для потребителей. Чтобы иметь возможность создавать эти интерфейсы, нам нужна CMS, которая делает несколько вещей хорошо:

  • На основе Java (потому что мы являемся магазином Java, это позволяет нам работать с теми же людьми на CMS и промежуточном программном обеспечении).
  • Горизонтально масштабируется до десятков серверов без лишних хлопот. В классическом случае при масштабировании на несколько серверов база данных и папка с ресурсами распределяются между узлами. Это может быть проблемой, когда у вас много узлов, но на практике это не такая большая проблема, потому что большая часть загрузки попадет в индекс, а не в db или на диск. В версии 2.5 и выше dotCMS предлагает режим "ничего общего", где каждый node имеет свою собственную базу данных и папку с данными, но это требует от вас использования дополнительного (считанного: лицензированного) сервера авторизации, который подталкивает контент к каждому из узлов, Я не играл с этой настройкой самостоятельно, но это звучит многообещающе, тем более, что каждый node может быть простой и дешевой коробкой, которая использует только postgresql/mysql и tomcat и потому, что больше нет точки отказа. В классическом случае, если папка с разделяемыми ресурсами или db умрет, все узлы также будут недоступны, за исключением случаев, когда вы кластерируете и db, и диск, который стоит делать. С этой настройкой "ничего общего" это уже не так. Как я уже сказал: у меня нет опыта в этом, но похоже, что это может сработать.
  • Интерфейс администратора, который можно использовать как для опытных пользователей, так и для нетехнических пользователей (клиентов). Не все "хорошо с компьютерами", но они также должны иметь возможность управлять контентом (очень часто эти люди работают в отделе маркетинга наших клиентов). dotCMS предлагает способы создания админ-интерфейсов, которые показывают только некоторые из функций dotCMS. Это мешает им понять всю систему, которая ускоряет обучение и принятие.
  • Структурированный контент. Это biggie. Мы хотим иметь возможность определять множество типов контента с фиксированным набором полей, как и таблица базы данных. Все без необходимости перестраивать или перезапускать систему. Люди, которые будут определять контент на основе этой структуры (имя dotCMS использует для этих типов), не могут вводить неверные данные, потому что система защищает их. Это делает создание веб-сайтов гораздо более перспективным и удобным. Специально для разработчиков.
  • Сначала сосредоточьтесь на контенте. В первые месяцы, которые мы использовали dotCMS, мы фактически использовали dotCMS для управления самим контентом и разоблачениями через API JSON. Мы не использовали функции CMS, такие как определение шаблонов и создание страниц. Это прекрасно работает и звучит как материал, который вы ищете. dotCMS имеет JSON/XML Webservice, который возвращает контент на основе запросов. Мы используем это почти во всех наших проектах, см. Здесь дополнительную информацию: http://dotcms.com/docs/latest/ContentAPI. Также возможно использование dotCMS для всего интерфейса. Особенно с поддерживаемыми контроллерами Spring и новым дизайнером шаблонов CSS-framework это хороший способ создания систем, для которых требуется не только некоторый контент.
  • Многоязычный. dotCMS предлагает несколько способов сделать это. Вы можете создавать контент на всех необходимых вам языках, даже не текстовое содержимое, такое как изображения. Из-за подхода "контент первый" многие вещи довольны dotCMS и могут рассматриваться как таковые, включая создание версии для каждого языка, который вам нужен.
  • Открытый исходный код. dotCMS предлагает версию сообщества, которую мы используем большую часть времени. Только для профессиональных функций, таких как балансировка нагрузки, использование oracle для базы данных и т.д., Необходима платная версия. И даже тогда затраты управляемы. Подробнее об этом см. http://dotcms.com/products/editions/.
  • Механизм внутреннего кэширования. Из-за высокой нагрузки некоторые из сайтов, которые мы создали, нуждаются в кешировании. DotCMS использует Google Guava для их кэширования, который работает очень хорошо.
  • Расширяемость, также большой. По очевидным причинам нам нужно было расширить функциональность dotCMS. DotCMS использовала только старый способ создания плагинов, который является довольно уродливым и основан на ant script, который перезаписывает классы dotCMS своим собственным. Он отлично работает, но я всегда чувствую себя грязным после написания такого плагина. Однако со 2-й версии они предлагают платформу плагинов на основе OSGi, которая очень милая и гораздо более дружественная для разработчиков. Он вышел из бета-версии в версии 2.5. Мы планируем переносить все наши плагины в новую структуру.
  • Несколько хостов. Нам нужно иметь возможность размещать несколько сайтов в пределах одной CMS. DotCMS обеспечивает это изначально. Это также хороший способ поделиться общим материалом между несколькими хостами, которые мы используем много.

Конечно, есть и нижние стороны. Вот несколько:

  • Веб-CMS, такие как dotCMS, хранят его содержимое в базе данных и активы как файлы на диске. Это делает управление версиями и синхронизацию между различными серверами болью в прикладе. Начиная с версии 2.5, dotCMS предлагает инструменты синхронизации, которые позволяют вам перемещать контент из одной среды (например, UAT) в другую (например, PROD), что помогает. Но неспособность проверить одну версию контента из чего-то вроде GIT или SVN очень раздражает. Тем более, что мы, как разработчики Java, привыкли к таким вещам, как автоматическое тестирование в непрерывной среде интеграции. Конечно, вы можете хранить базу данных как инструкцию SQL и каталог ресурсов, но медленный и не очень "приятный". Но опять же все системы, которые хранят состояние в базе данных, имеют этот недостаток.
  • DotCMS занимает некоторое время, чтобы учиться. Это не маленькая CMS, как Wordpress, которую вы поймете за один день. Он имеет много функций и очень мощный, но вам, скорее всего, понадобится день или около того, чтобы понять способ dotCMS, а затем еще пару дней, чтобы понять все API. Я рекомендую вам сначала прочитать некоторые документы и поработать с ним, прежде чем строить настоящий сайт: многие пути ведут к Риму, но некоторые из них состоят из зыбучего песка.:)
  • DotCMS - головоломка с ОЗУ. Чтобы все было в порядке, оно кэшировало все, поэтому, если у вас много контента, он будет убираться в имеющейся у вас оперативной памяти. Вы можете настроить это, но проще просто дать ему достаточно оперативной памяти, которую мы нашли.
  • Не все конфигурации клиента редактирования WebDAV + совместимы с dotCMS. Например, на mac я обнаружил, что лучше всего использовать Cyberduck в качестве клиента WebDAV и Aptana в качестве текстового редактора. Другие настройки делают причудливые вещи, которые dotCMS не очень нравится. Вы должны немного поиграть, чтобы узнать, какая для вас самая лучшая настройка. Я обнаружил, что если вы зарегистрируете ошибку на github, они исправят ее в следующей версии. Они сказали мне, что WebDAV трудно понять, потому что это не фиксированный стандарт, который я понимаю, но он все еще может быть болью в заднице.

Если вы хотите узнать dotCMS, прочитайте их -не так плохо-документацию: http://dotcms.com/docs/latest/TableOfContents, а также посмотрите их демонстрационный сайт (http://dotcms.com/products/demo/). На демо-сайте вы найдете примеры всех концепций, которые предлагает dotCMS. О, и проверить наши собственные бесплатные плагины dotCMS, а также. Особенно рекомендуется JavaScript и CSS minifier: http://geekyplugins.com/.

Надеюсь, это немного поможет. Дайте мне знать, если вы хотите узнать больше.

Ответ 2

Отказ от ответственности: я работаю для Hippo, поэтому я постараюсь ответить только с фактами, а не с мнением: -)

  • Hippo полностью основан на Java, интерфейс не зависит от языка, но ориентирован на JSP или Freemarker, при желании вы можете использовать REST-интерфейс и использовать что угодно.

  • Многие плагины создаются и собираются в Hippo forge.

  • Контент-ориентированный дизайн был основным продуктом разработки Hippo, не должен вызывать проблем.

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

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

  • Многоязычный легко, часть многоканальной настройки по умолчанию.

  • Публичное издание (полное, без наживки и переключателя) является открытым исходным кодом, существует корпоративная функциональность за лицензия на собственность. Лицензия также открывает возможности поддержки, помимо группы Google и.

Теперь, по вашему комментарию о неполной документации, позвольте мне высказать свое мнение: Вы правы, документация - это постоянная борьба. Большинство материалов документировано, но их трудно найти. Мы работаем над улучшением обзоров, интродукций и учебников, но мы, очевидно, еще не закончили. Если вы ничего не можете найти, обычно сообщество может помочь вам и направит вас в правильном направлении.