Is any portlet type considered "best practice"?

[Patrick Conley, modificado 8 Anos atrás.]

My company is migrating to Liferay, and we're trying to decide what kind of portlet to use for new development.

• Obviously, portal UI code is written in JSP, so that's presumably the popular choice for now. Then again, the tutorials and learning paths use a lot of scriptlets, so maybe the portal isn't completely modern.
• JSF portlets seem like an interesting choice, since they use AJAX and still have AUI support
• Vaadin portlets are supported by project wizards, but according to Stack Overflow statistics, they seem to be hardly used.
• Velocity portlets are tempting because all our existing code uses Velocity templates, but the VelocityPortlet class isn't part of the public API. Will it become public in the future?
• I'm ignoring the dozen or so types of scripting portlets described in the API docs because we want templates.

Are any of these types particularly recommended? Will the recommendations change at all for version 7? Will Liferay stop (or start) supporting any of these?

Sorry if this is just an unanswerable request for opinions.

[Neil Griffin, modificado 8 Anos atrás.]

Hi Patrick,

Congratulations on migrating to Liferay!

When it comes to choosing a portlet framework, Liferay is technology-agnostic. It is our goal to provide developers with as much choice as possible.

The bulk of the UI for Liferay Portal 6.2 is developed with JSP technology. But many of the Liferay JSP tags rely on AlloyUI in order to manifest JavaScript UI components.

Liferay EE subscribers enjoy support for:
1. Plain Java-based portlets that extend javax.portlet.GenericPortlet and/or use a PortletRequestDispatcher to dispatch to a JSP. Developers can use the same JSP taglibs that are used by Liferay's core UI.
2. Liferay's MVCPortlet which provides a lightweight MVC framework for JSP.
3. Liferay Faces, which enables developers to build portlets with JSF. We provide Liferay Faces Alloy as a component suite for AlloyUI, but also make it possible to use PrimeFaces, ICEfaces, and RichFaces as a 3rd party component suite. JSF provides the Facelet templating engine which has concepts familiar to Velocity developers.

Although not included with an EE subscription, Liferay also has technology partnerships with PrimeTek Informatics (maker of PrimeFaces), ICEsoft (maker of ICEfaces), and also Vaadin.

Regarding Velocity portlets, it is true that VelocityPortlet.java is not part of the public API. However, it is a very small amount of code (one class) that can be easily maintained and/or extended by your organization.

When making a choice, I would echo the advice of David Nebinger (Liferay's top forum poster) who recommends "go with what you know." In other words, if you have a development team that has expertise with Velocity, then you might be able to develop faster if you choose Velocity. If you have new development teams that need to learn a new technology anyway, then maybe it would be good to develop some demo/test portlets in a few different technologies to see which one is best for your team.

Kind Regards,

Neil

[Neil Griffin, modificado 8 Anos atrás.]

Apologies, I forgot to answer these questions:

Patrick Conley:

Will the recommendations change at all for version 7? Will Liferay stop (or start) supporting any of these?.

Any of the technologies discussed should continue to work in Liferay 7. For more information, see the Blade project which contains various demos for OSGi portlets. I also recommend that you watch Liferay Developer Tools for Liferay 7 with Greg Amerson.

The Liferay Faces team also has plans to create a new JSF component suite for metal.js and CrystalUI which is the planned successor to AlloyUI.

Additionally, I forgot to mention Spring Portlet MVC which is also a popular technology.

[Patrick Conley, modificado 8 Anos atrás.]

Thanks. I've created example portlets using a several technologies already, so we'll just continue to argue amongst ourselves over which we prefer.

[David H Nebinger, modificado 8 Anos atrás.]

Patrick Conley:

Obviously, portal UI code is written in JSP, so that's presumably the popular choice for now. Then again, the tutorials and learning paths use a lot of scriptlets, so maybe the portal isn't completely modern.

It's also based on Struts 1... I wouldn't use the portal's implementation as the "best practice" recommendation, it was just the right tool at the time.

Vaadin portlets are supported by project wizards, but according to Stack Overflow statistics, they seem to be hardly used.

This is unfortunately true, but it is what it is. Rich Internet Application frameworks like Vaadin can carry a heavy server-side impact, but if you have a team of java, non-web developers Vaadin can give your team the ability to create responsive portlets w/o having to learn a lot of HTML, CSS and JS (doesn't negate it, but can lower that portion of the learning curve).

Velocity portlets are tempting because all our existing code uses Velocity templates, but the VelocityPortlet class isn't part of the public API. Will it become public in the future?

Well, velocity is a good templating engine but I don't know if it would really work well as a portlet implementation framework. Just my opinion, of course.

So me, I've recently been on an "angular portlet" tear. It's fun adapting this stuff to work within the Liferay environment, but it is doable.

As Neil points out, I'm fond of recommending that you "go with what you know". The important part to realize going into your journey is that there is a considerable learning curve in front of you. You may not be able to see just how big it is at this point, but it is still there.

Using what you already know will help knock a chunk out of that learning curve, bringing you that much closer to being successful Liferay developers and implementors.

Sure you can pick an ancient technology like Struts 1 or a modern one like Angular or something else. Likely you can get it to work if you have enough time, money and resources. Each framework is going to come with their own plusses and minuses, it's just a matter of determining if you can live with whatever restrictions your choice imposes.