Liferay - Open-Source J2EE Portal
Only yesterday I finished my first full-featured portlet for Liferay (SVN / Mercurial / CVS browser) - and I want to share some experience (albeit minimal). In addition, according to Liferay, nothing has run through Habré yet. The article is very superficial - but nevertheless, I hope, will give some initial presentation.
')
If in a nutshell - Liferay is a portal made on J2EE technologies (ok, it turned out more than two words). You can see it on the site www.liferay.com . Also, it would be easier to present what you are talking about - here are similar products, but made on other technologies:
The portal allows you to combine different modules in one web application (and on the same web page). Speaking of Liferay is
Plus, there is the possibility of developing your own modules, called portlets (Portlet).
A portlet is a component that runs in the context of a Portlet Container and is responsible for rendering the page area provided to it (as opposed to drawing the entire page in a regular servlet)
Like many other technologies in J2EE, the portlet API is standardized via JSR (Java Specification Request). JSR-168 (Portlet 1.0) & JSR-268 (Portlet 2.0) are responsible for portlets, as well as a number of other JSRs (for example, JSR-301 - Portlet Bridge Specification for JavaServer Faces)
The presence of standards allows you to develop portlets, which can then be performed in any portal. In addition to Liferay, there are a number of other Open-Source implementations (not to mention commercial):
But, in my humble opinion, Liferay is the most powerful and full-featured of them, for good reason Sun chose Liferay as the basis for its WebSpace portal.
Standards are good! It is even very good! But, if you take a specific example (my portlet) - then I decided to develop a portlet just for Liferay - that is, not working on other portals. Why? Well, firstly, I strongly doubt that my portlet will be used somewhere other than Liferay (if someone wants to do it, I’ll do the general version), and sharpening the portlet just under Liferay allows you to use a large set of additional services and workpieces.
In my case, the table drawing tag came in handy for me: you form a data set - and display it as a table with this tag - as a result you get a table styled like all other tables in Liferay, with data partitioned into “pages” (pagination) , navigation between pages, control the number of elements on one page. Since the table is present on almost every form, this was critical for me and using Liferay-specific functionality made my life much easier.
But, in each project, I think it should be decided individually - if possible - it is better to follow the standards (and ensure portability) - but if portability is not needed and the solution is created for a specific portal - you can also use specific services and functionality.
Also, Liferay was chosen because the set of technologies used in it and its portlets is close to my EmForge - and I hope in the future to get closer integration of EmForge & Liferay:
When developing the Portlet user interface for Liferay, you can use almost all the frameworks that are used when developing a regular java web application:
You can write on JSF - but working with naked JSF is sad, but of the additional frameworks are supported by IceFaces and only yesterday the forum announced the announcement of support for RichFaces (but apparently in the alpha state)
Other frameworks should work, but - it is necessary to check (there may be "nuances"). For example, no one was able to confirm to me whether Wicket will work or not.
The development of portlets is much similar to the development of ordinary web applications on java - the project structure is much the same, the same web.xml - there are just a number of additional configuration files, and the whole program is executed in a slightly different context - instead of Servet and Filter ov - Portlets and PortletFilters
The main difficulty is very little documentation :( - all that is is a collection of poorly structured wiki on liferay.com, plus posts in forums. For me, the best documentation was the source code for Liferay itself and its native portlets. Just when you need to do something - you are looking for a portlet with similar functionality, you look at its source code and do it in the same way (good - everything is in Open-Source and is available)
I really liked Liferay - and if you need to write a CMS in java - think about it - maybe you don’t need to reinvent the wheel? Using Liferay, you get a site with user management and roles, a lot of components and the ability to expand it into java - all in Open Source and for free.
')
What is Liferay
If in a nutshell - Liferay is a portal made on J2EE technologies (ok, it turned out more than two words). You can see it on the site www.liferay.com . Also, it would be easier to present what you are talking about - here are similar products, but made on other technologies:
- Microsoft SharePoint
- Joomla / Drupal for PHP
- With a certain stretch of iGoogle & Google Site
The portal allows you to combine different modules in one web application (and on the same web page). Speaking of Liferay is
- Full CMS
- Wiki
- Blogs
- Forums
- The latest version adds the functionality of social networks: friends, "wall", messages
- And many, many, many other things.
Plus, there is the possibility of developing your own modules, called portlets (Portlet).
A portlet is a component that runs in the context of a Portlet Container and is responsible for rendering the page area provided to it (as opposed to drawing the entire page in a regular servlet)
Like many other technologies in J2EE, the portlet API is standardized via JSR (Java Specification Request). JSR-168 (Portlet 1.0) & JSR-268 (Portlet 2.0) are responsible for portlets, as well as a number of other JSRs (for example, JSR-301 - Portlet Bridge Specification for JavaServer Faces)
The presence of standards allows you to develop portlets, which can then be performed in any portal. In addition to Liferay, there are a number of other Open-Source implementations (not to mention commercial):
But, in my humble opinion, Liferay is the most powerful and full-featured of them, for good reason Sun chose Liferay as the basis for its WebSpace portal.
Standards / non standards
Standards are good! It is even very good! But, if you take a specific example (my portlet) - then I decided to develop a portlet just for Liferay - that is, not working on other portals. Why? Well, firstly, I strongly doubt that my portlet will be used somewhere other than Liferay (if someone wants to do it, I’ll do the general version), and sharpening the portlet just under Liferay allows you to use a large set of additional services and workpieces.
In my case, the table drawing tag came in handy for me: you form a data set - and display it as a table with this tag - as a result you get a table styled like all other tables in Liferay, with data partitioned into “pages” (pagination) , navigation between pages, control the number of elements on one page. Since the table is present on almost every form, this was critical for me and using Liferay-specific functionality made my life much easier.
But, in each project, I think it should be decided individually - if possible - it is better to follow the standards (and ensure portability) - but if portability is not needed and the solution is created for a specific portal - you can also use specific services and functionality.
Also, Liferay was chosen because the set of technologies used in it and its portlets is close to my EmForge - and I hope in the future to get closer integration of EmForge & Liferay:
Portlet Development
When developing the Portlet user interface for Liferay, you can use almost all the frameworks that are used when developing a regular java web application:
- Naked JSP - which I chose for now, since I only have data mapping
- Struts 1.x - used to write "native" portlets, and therefore has a lot of "blanks"
- Struts 2 should work too
- Spring-MVC
You can write on JSF - but working with naked JSF is sad, but of the additional frameworks are supported by IceFaces and only yesterday the forum announced the announcement of support for RichFaces (but apparently in the alpha state)
Other frameworks should work, but - it is necessary to check (there may be "nuances"). For example, no one was able to confirm to me whether Wicket will work or not.
The development of portlets is much similar to the development of ordinary web applications on java - the project structure is much the same, the same web.xml - there are just a number of additional configuration files, and the whole program is executed in a slightly different context - instead of Servet and Filter ov - Portlets and PortletFilters
Development Difficulties
The main difficulty is very little documentation :( - all that is is a collection of poorly structured wiki on liferay.com, plus posts in forums. For me, the best documentation was the source code for Liferay itself and its native portlets. Just when you need to do something - you are looking for a portlet with similar functionality, you look at its source code and do it in the same way (good - everything is in Open-Source and is available)
Where to use
I really liked Liferay - and if you need to write a CMS in java - think about it - maybe you don’t need to reinvent the wheel? Using Liferay, you get a site with user management and roles, a lot of components and the ability to expand it into java - all in Open Source and for free.
Source: https://habr.com/ru/post/60712/
All Articles