Что нас ждет в Liferay 7.0

    Компания Liferay объявила о выходе последней milestone версии Liferay 7.0 m7. Это означает что дальше пойдут уже альфы и беты, в которых будет идти исправление ошибок — функциональных же изменений уже особо не ожидается. И хотя до релиза еще примерно полгода, уже сейчас можно посмотреть что же нового нас ждет в новой версии Liferayimage

    Что такое Liferay?


    Сначала небольшое вступление для тех, кто не знает что такое Liferay. Если в двух словах — это SharePoint, но на Java и Open-Source.
    Если очень упрощенно — то это самое точное определение. Хотя все конечно не так просто и так прямолинейно.
    Если чуть подробней — это веб-портал, разрабатываемый на технологиях Java Enterprise Edition (о технологиях чуть ниже) по схеме Open Source. При этом есть компания, которая занимается целеноправленным развитием данного продукта и оказывает Enterprise- поддержку (уже за деньги). Liferay можно применять
    • и классически — как внутрикорпоративный портал (организация совместной работы сотрудников) или корпоративную соцсеть,
    • и для создания внешних сайтов (один из примеров — недавно упоминавшийся на хабре сайт мобильного оператора Yota),
    • а можно использовать его как платформу для разработки своих приложений (очень хорошо на нем получаются различные B2B и B2C решения).


    Подробней можно почитать на самом сайте Liferay или у нас (уже на русском).

    Изменения в архитектуре


    Основным новшеством, из-за которого новая версия будет 7.0 а не (например) 6.3 это переход на OSGI. Это огромное изменение в плане внутренней архитектуры (да и всей экосистемы вокруг Liferay, так как это влечет за собой и изменения в разработке плагинов). Когда-то давно-давно, Liferay базировался на EJB. EJB тогда были вторые, они были большие и тяжелые, и требовали больших и тяжелых серверов для запуска (минимум JBoss) — что не всегда было оправданно. Потом Liferay перевели на легкий Spring Framework — и этого задела ему хватило лет на 7 (могу ошибаться в какой точно версии произошел этот переход — но достаточно давно). И вот теперь OSGI. Что это дает пользователям (хотя скорее программистам, реализующим решения на базе Liferay — конечным пользователям все равно на каких технологиях сделано):
    • Ядро портала теперь модульное. Можно легко отключить лишнее. Один из минусов Liferay называли, что в его ядре много «лишнего». Ставя Liferay пользователи получали не только Portlet Container и админку с необходимым базовым функционалом — но и кучу модулей, причем необходимость некоторых из них вызывала большие сомнения. Теперь можно будет сформировать свой набор модулей, которые мы хотим что бы вошли в ядро
    • Все плагины (дополнения к порталу) разрабатываются теперь как OSGI модули. Раньше каждый плагин был отдельным web-приложением (с точки зрения Application Server-а) которое общалось с порталом через хитрый механизм под названием BeanLocator (который был по сути дела хаком). Теперь все честно, все строго в рамках базовых технологий
    • Проще вносить изменения в само ядро портала. Просто замените модуль реализующий требуемую функциональность на свой. Все, надеюсь больше не потребуется никаких ext-плагинов (кто занимался глубокой кастомизацией Liferay, тот поймет)

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

    Чего к сожалению не ожидается:
    • Сервером по умолчанию по прежнему остается Tomcat 7. На самом деле очень хотелось бы увидеть Tomcat 8 и использование WebSockets в портале
    • Реализация веб-сервисов по прежнему на первом Axis. Тут без слов. Видимо придется ждать 8-ой версии.

    Изменения в UI


    Большие изменения ожидаются в пользовательском интерфейсе:
    • Новая тема. Обещают более «легкую», mobile-friendly и все такое. Так же и более кастомизируемую. Пока сложно оценить что за этим стоит, но если сделают надпись «Powered by Liferay» отключаемой или конфигурируемой — это будет большим шагом вперед :)
    • Новое управление. Всем. Нет теперь отдельной Control Panel-и. Есть Product Menu (вылезает слева). Управление страницей из боковых кнопок перекочевало в подвал страницы. Ну и многое другое. Тут я чувствую придется долго привыкать

    image
    • Загрузка страниц Ajax-ом: многие портлеты теперь могут загружать свой контент без перезагрузки страницы (например переход из списка блогов к конкретной записи). Важно — что такая поддержка на уровне базового framework-а, так что ее можно использовать везде.


    Audience Targeting


    На самом деле плагин Audience Targeting доступен уже и в 6.2, но в 7-ке он должен раскрыться во всей красе. Что это такое? Это сегментирование пользователей портала (по различным критериям) и отображение различного контента для различных сегментов. Плюс поддержка компаний. Базовый функционал для любой уважающей себя CMS наконец-то стал доступен и в Liferay (а как нам его не хватало!)
    Понятно, что (например) геолокацию и сегментирование по регионам России придется дописывать — но это (смотрим выше на OSGI) можно будет уже сделать просто отдельным плагином.

    Новый редактор


    Liferay продолжает смелый эксперимент по внедрению своего нового, инновационного редактора. Нет больше никаких тулбаров и кнопочек. Только контекстное редактирование
    image
    Тоже такое решение — на любителя. У меня например есть клиенты, которые просят выкинуть из Liferay 6.2 CKEditor 4 и ввернуть старый FCKEditor 3, ибо он «больше похож на старый ворд которым все привыкли пользоваться». Вот и как им объяснять про инновационное контекстное редактирование?
    Благо что можно легко настраивать какой именно редактор используется

    Геопривязка контента


    Можно теперь привязать любой контент к географической точке и строить (например) интерактивные карты
    image

    Шаблоны для Staging-а


    В Liferay есть такая штука как Staging — это когда вы на отдельном (тестовом) сайте подготавливаете все необходимые изменения (новые страницы, новый контент) и потом по нажатию кнопки (или по расписанию) после прохождения необходимого согласования публикуете на рабочем сервере. Штука полезная, так как (например) позволяет не «ломать» нагруженный продуктовый кластер а спокойно делать свои изменения на тестовом сервере и потом публиковать их ночью на прод. Правда в жизни вылезает куча нюансов — и кто работал в Liferay со staging-ом по достоинству оценит возможность запоминать конфигурацию для stage в виде шаблонов для повторного использования.

    На самом деле это лишь небольшой список основных изменений. В ходе работы над новой версией ребята из Liferay уже выполнили огромную работу (только в рамках Liferay 7.0 m7 закрыто порядка 170-ти User Story) и очень хочется надеяться что они доведут работу до конца (с хорошим качеством) и через полгода мы увидим новую версию.
    Поделиться публикацией

    Похожие публикации

    Комментарии 11
      0
      А есть ли где посмотреть живое демо?
        0
        Напишите нам на www.emdev.ru/order-demo свои координаты — перешлем информацию по доступу к демо-стенду
        0
        Опасаюсь таких решений после негативного опыта с альфреской.
          0
          А каких решений не опасаетесь?
          Ну и — не знаю что у вас произошло с Альфреской — но были негативные отзывы о Liferay. Мне кажется общая проблема в следующем — системы (что Alfresco, что Liferay) достаточно сложные — для реализации более-менее сложных задач требуется опыт. Зачастую же складывается как — берут (потому что бесплатно) — сажают админа или unior-разработчика — мол «поковыряйся — что там и как», потом кое-как решают поставленную задачу — она нифига не решается, все работает плохо и криво, а итоге решают что продукт «отстой» и все выкидывают.
          Мне конечно обидно такое наблюдать — так как проблема в данном случае не в продукте — а в умении с ним обращаться — но такие ситуации встречал не раз.
            0
            Ну могу с вами согласиться akakunin, на моей практике с альфреской работала команда зрелых программистов и 90% из них плевалась от нее, а некоторые уходили с проекта. Самое плохое в таких решениях это то что мы принимаем правила игры видясь на эти плюшки что вы описываете в своей статье, а потом понимаем что проблем и ограничений (websockets в вашем случае) на порядок больше но время уже ушло.
            Я не рискну утверждать какие могут быть проблемы у liferelay но я уверен что они есть, будь то горизонтальное масштабирование или использование в связке с документо ориентированным хранилищем.
            А не опасаюсь я простых решений, посмотрите например на jhipster, это совершенно другой подход который не навязывает то как ты будешь решать задачу и какие технологии будешь использовать. Монолит или микро сервис, документо-ориентированная субд или реляционная, websockets или long polling. Все в руках разработчиков. Именно в сторону упрощения и ускорения разработки движется индустрия, а не в сторону таких монструозных решений.
              0
              Коллега — поддерживаю вас в ваших опасениях — сам не раз сталкивался когда «покупались» на красивые маркетинговое демки и потом огребали по полной. Но тот же Liferay я выбирал в свое время именно как программист, и за практически 7 лет в выборе не разочаровался. Да — есть минусы и органичения. Да — есть моменты когда Liferay просто выбешивает — но идеальных решений не бывает — всегда идет компромис между плюсами и минусами — и для меня плюсы Liferay перевешивают его минусы.
              Спасибо за jhipster — я как раз хотел посмотреть что есть сейчас из высокоуровневых framework-ов способных решать близкие по сложности задачи (в списке были Entando и Cuba, добавлю еще и jhipster).
              Но — это все таки не совсем то. Просто пример — модель безопасности. Да — есть Spring Security — но в плане ролевой безопасности его возможности по реализации (насколько я помню) ограничены. Есть задача — назначать на любые сущности разрешение для любой роли на «Просмотр» (ну и другие разрешения). Возникают объекты (в разных системах они называются по разному — но смысл примерно один и тот же): User, Role, Resource, Permission — и соотвественно возможность назначать на определенный Resource Permission «View» для определенной Role.
              А теперь ситуация — таблица с миллионами записей (Resource-ы) и надо для конкретного пользователя User который входит в несколько Role-ей показать таблицу (с шагом записей 20 штук) только тех объектов которые он может смотреть…
              jhispter даст нам решение этой задачи? Сомневаюсь. Писать самому модель безопасности — можно. Но я например наблюдаю прогресс в реализации модели в Liferay и вижу что если 6 лет назад там делалась выборка из базы и фильтрация средствами Java — то сейчас уже формируются 10-ти этажные sql-запросы, но фильтрация объектов с учетом прав доступа осуществляется на уровне базы с соотвествующей производительностью. И вот сколько времени займет такое реализовывать самому — я даже затрудняюсь ответить.

              Потому — для каждой задачи — свой инструмент. Где-то да — проще самому разработать систему (не с нуля — а используя в качестве отправной точки какой-то framework или стек — будь то jhispter, entando, cuba и так далее — список можно продолжить) — а где-то (для более сложных задач) проще все-таки взять готовый продукт и допиливать его (благо open source и исходники есть).
                0
                А теперь ситуация

                Не стоит ожидать решения от jhipster это всего лишь генератор шаблона проекта на популярном стеке технологий. У вас будет полная свобода по решению этой задачи стандартными способами. Я не говорю уже о том что в документо ориентированной субд такой проблемы просто не возникло и возможно для СЭД лучше не прикручивать ACL, а сменить СУБД.
          0
          По работе пришлось повозиться с Liferay. Осталось весьма плохое впечатление. Монстроузное приложение под 300 метром. Документации особо нету, постов и ответов почти нет, код ужасный.

          Совершенно не понимаю зачем может понадобиться такая штука.
            0
            Ну не соглашусь с вами.

            Да — приложение достаточно сложное. По моим прикидкам время «входа» — до полугода. 300 метров — ну так это приложение Enterprise уровня. Сравните с другими лидерами гантера (SharePoint, WebSphere Portal, SAP, Oracle) — те еще больше и монструозней — на их фоне Liferay супер легкость и простота.

            Документация — dev.liferay.com — сейчас вполне вменяемая. Форумы — www.liferay.com/community/forums/-/message_boards/recent-posts — практически нет постов без ответов.

            Код — вполне вменяемый.
              0
              У меня три года опыта с Liferay, особенно скриплеты на jsp страницах доставляют. А уж про монстра в виде AUI я вообще молчу.

              Лично мое мнение — если требуется базовый функционал с минимальными модификациями — Liferay просто нет альтернативы, мощный API, куча готовых портлетов, маркетплейс. Если же хотя бы немного нетривиальные задачи — и разработка превращается в увлекательное плавание по остаткам документации и курении форумов с ответами вида «ну вот тут как бы где-то посмотрите там», поэтому предпочту с нуля делать чем бодаться с Liferay.
            0
            На текущем проекте навязали использовать liferay для того чтоб сдать проект за 4 недели. Времени разобраться конечно не особо, но так как я фронтендщик и макеты довольно сложные — я вообще не понял как для современного сайта можна использовать это, простите, г-но. Вечные проблемы с деплоем, кешированием и еще черти-чем. Выпиливание бутстрапа2 и подключение хоть сколь вменяемых фреймворков и либ которые действительно ускорят разработку — тот еще геммор. Да и просто достаточно погуглить отзывы про лайфрей и понять что они негативны да и сам лайфрей технология прошлого которая так и не взлетела, но все-равно люди продолжают вставать на эти грабли. Я еще не разобрался кто нам навязал этот лайфрей на проекте без права отказаться и выбрать свое, но сделал это кто-то очень и очень подлый или же далекий

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое