Ограничения/недостатки разработки портлетов для [закрытого] Liferay
Я закончил тем, что нашел решение с помощью некоторой умной работы с условными операторами IF (). Я думаю, что ключом было то, что слитые ячейки, которые не были верхними (т. Е. Если я объединил A2: A4, A2 - верх, A3, A4 - низ), были равны 0, в то время как для вершины было установлено значение текст в объединенной ячейке. Используя приведенную ниже формулу, я смог добиться результата, который мне был достигнут:
=MOD(IF(ROW()=2,0,IF((A2=0),IF((OR(A1<>0,A2=A1)),F1, F1+1),F1+1)), 2)
А вот связанный скриншот: https://imgur.com/a/ gNaC62c
Затем я просто добавил условное форматирование для каждой строки, кроме строки 1: =$F2=1. Я буду скрывать столбец F, чтобы он казался менее навязчивым.
Для дальнейшего использования я бы согласился с тем, что @BruceWayne упомянул в том, что более простое форматирование, обеспечивающее выполнение работы, было бы предпочтительным. Есть много других способов отформатировать это таким образом, который имеет гораздо больше смысла, но я чувствовал, что был близок, когда я возился с этим, поэтому я оставался с ним еще 15 минут или около того и смог вытащить пригодное для использования форматирование состояние.
7 ответов
(Отказ от ответственности: я один из разработчиков Liferay)
Я думаю, что оба варианта хороши в зависимости от ваших потребностей. Если у вас есть предыдущий опыт разработки автономных веб-приложений, но нет опыта разработки портлетов, то выбор первого поможет вам начать работу быстрее. Недостатки заключаются в том, что вам придется реализовать свои собственные пользователи и систему разрешений, и вы не сможете использовать услуги портала, предоставляемые Liferay. Если вы решите использовать эту альтернативу, обратите внимание, что вы можете развернуть обычные файлы WAR в Liferay, и он автоматически создаст простой портлет, который использует iframe для отображения вашего приложения. Это позволит вам разместить отдельное приложение вместе с портлетами на страницах Liferay.
Разработка портлета для Liferay окупается, когда вы начинаете использовать услуги портала, которые он предоставляет. Чтобы начать с разработки портлета, вы можете забыть о разработке собственной пользовательской системы и использовать ту, которую предоставляет Liferay (которая довольно эффективна). Вы также можете использовать другие службы, такие как разрешения, комментарии, теги, категоризацию, определение объема данных и т. Д., Что позволит вам разработать довольно полное приложение за более короткое время. Недостатком является то, что в первый раз вам придется изучить несколько новых вещей, но во второй раз вы пойдете намного быстрее.
Надеюсь, это поможет.
Я всегда думал, что такие порталы, как Liferay, следует рассматривать как сродни общей инфраструктуре. Они предоставляют общий способ доступа к приложениям, общим службам (например, аутентификации) и стандартному способу развертывания, но за счет производительности.
Если вы намерены развернуть на Портале не только это приложение, то да, это, вероятно, уместно, поскольку вы получите экономию времени / средств от того, что вам не придется разрабатывать эти общие службы во второй раз. И последующие приложения будут выглядеть и вести себя аналогично этому.
Однако, если это единственное приложение, которое нужно развернуть, тогда издержки портала не стоят того, и вам лучше идти с нормальной веб-приложение.
Liferay и портлеты в целом отлично подходят для очень специфического класса приложений. Если вы работаете в ИТ-отделе и вам необходимо объединить приложения для нескольких отделов или для нескольких отделов, то вам подойдут портлеты. Теоретически вы можете добавить портлеты от разных продавцов, и все они будут жить в гармонии в одной среде.
Однако, если вы создаете приложение, которое является одним из следующих
1), созданное полностью одной командой 2) имеет единый источник требований 3) имеет требования, которые не являются подмножеством функций, доступных в контейнере портлета. 4) has a graphic designer that isn't willing to live within the confines of portal style applications.
then sticking with something like Spring would be the way to go.
Spring and its many sub-projects provide a lot of the shared services and infrastructure offered by portlets but they are offered in an open and more flexible way. You can pick and choose what you want.
Portlets make a lot of the design decisions for your in terms of authentication and authorization, navigation and layout. If the plans you have for your application fall outside of those decisions you will spend a lot of time creating workarounds to try and get it to do what you want.
Я использую Liferay уже около 2 лет для внутреннего приложения. Мы обсуждали одно и то же много раз на протяжении всего цикла разработки перед нашим первым выпуском. Нам несколько раз приходилось сражаться с Liferay, иногда из-за нашего собственного незнания, иногда из-за среды портлета, а иногда из-за Liferay.
Если вам нужны варианты макета для нескольких приложений, которые вы можете получить с портала , то вам непременно стоит использовать Liferay. Если вы пишете одно приложение, то я бы, наверное, не использовал Liferay. Я думаю, что гибрид некоторых Liferay и некоторых других - безусловно, худший вариант.
Мы, вероятно, не используем Liferay в полной мере, но если это ваше первое приложение Liferay, то, скорее всего, вы этого не сделаете из-за кривая обучения. Первоначально мы надеялись иметь много разных портлетов для различных аспектов нашего приложения, но из-за отсутствия хороших механизмов взаимодействия между портлетами во время разработки (до JSR-286) мы закончили писать одно приложение. Теперь, когда мы оказались в этой лодке, мне жаль, что мы не обошлись без Liferay, поскольку все, что мы на самом деле используем, - это некоторые возможности управления пользователями.
Мы используем JSF и фейслеты (обе новые технологии для нас, поэтому, возможно, мы сами inclicted), и хотя у нас это получилось лучше, кажется, что нам пришлось преодолеть несколько препятствий, чтобы заставить его работать в портлете правильно; То, чего не должно было случиться в обычной среде веб-приложений. Для многих фреймворков поддержка портлетов кажется второстепенной. Очевидно, это не относится к Liferay, это ' это всего лишь побочный продукт работы в среде портлета.
В веб-приложении, использующем Spring MVC, Struts, Faces, Wicket и т. д., вы будете иметь гораздо больший контроль над всем, но также будете нести ответственность за реализацию большего количества вещей.
В портлете вы будете подчиняться условиям JSR-168 и / или JSR-286. Контейнер портала предоставит вам некоторые функции, такие как аутентификация пользователя, но IMO, весь портал для аутентификации пользователя слишком тяжел. Я вижу мощь портала в том, что он позволяет пользователю настраивать представление нескольких приложений, а не представлять одно приложение.
Вам следует ознакомиться со спецификациями, относящимися к портлетам, и посмотреть, соответствует ли они вашим потребностям.
http: // developers.sun.com/portalserver/reference/techart/jsr168/
Liferay имеет функции CMS и может интегрироваться с внешними платформами CMS, такими как Alfresco.
Liferay - чрезвычайно мощная система, существует множество сервисы и приложения доступны в готовом виде, но самым большим недостатком является отсутствие документации. Невозможно узнать все, просто глядя на код, поэтому, на мой взгляд, если у вас нет опыта, не выбирайте Liferay.
Чувак, оцените это решение IDE Netbeans + плагин PoralPack3.0 + комплект Liferay 5.2. Пакет Portal Pack здесь помогает вам, предоставляя удобный редактор графического интерфейса для файла service.xml, в котором вы можете определять сущности или структуры базы данных и с помощью того же графического интерфейса вы можете генерировать код услуг, который можно использовать внутри вашего портлета.
Для получения дополнительной информации проверьте приведенную ниже ссылку: http://www.liferay.com/web/satyaranjan/blog/-/blogs/portal-pack-:-write-database- portlet-using-service-builder plug-in