Liferay offers an enriching environment for developers aiming to build applications. Web apps, as defined by Wikipedia, run over networks like the internet or intranet.

Portal applications, a subset of web apps, coexist harmoniously with other applications, harnessing the portal platform’s features. This not only cuts down development duration but ensures consistency for users.

If you’re eyeing Liferay to host your applications, understanding the most efficient techniques is crucial. Liferay principally uses two methodologies: Portlets and OpenSocial gadgets.

Portlets:

Written in Java, Portlets are compact web applications functioning within a web page segment. Portlets stand central to portal systems since they embody the actual functionalities, while their container amalgamates these portlets per page.

Being self-contained, portlets present a non-invasive extension route for Liferay application development. They’re deployed as plugins, causing no downtime and can be split into dynamic segments on a page.

Various Java frameworks, including Liferay’s MVC Portlet and Alloy Portlet, support portlet creation. Owing to Java’s comprehensive technology suite, portlets can cultivate sophisticated applications.

OpenSocial Gadgets:

These typically are minor applications crafted with browser-based technologies like HTML and JavaScript. They resemble portlets but don’t stick to backend technologies like Java EE or Python.

Their primary focus lies in social applications, offering APIs to fetch data like user profiles. Liferay introduces two deployment types for OpenSocial gadgets:

1. Remote gadget: Hosted externally, yet displayed as native. Its reliance on the remote server can be a drawback in certain intranet scenarios.
2. Local gadget: Directly deployed on the Liferay server, akin to portlets.

Post-deployment, the gadget emerges as an application, granting administrators the privilege to integrate them into site pages. Interestingly, Liferay enables portlets to metamorphose into OpenSocial gadgets. This translates to portlets being accessible as remote gadgets across different portals.

Integrating Pre-existing Web Applications:

For those with non-portlet, non-gadget applications, a myriad of alternatives exist:

• Refactor the application into a portlet.
• Develop intermediary portlets connecting with the app through Web Services.
• Design an OpenSocial gadget encapsulating the app using IFrames.
• Innovate a portlet that syncs with the distant app via IFrames or HTTP proxy, necessitating single sign-on between both.
• Conversion pathways exist for apps with specific frameworks like Struts 1.x or JSF.

Diving into the Supported Frameworks:

Liferay thrives on its adaptability, endorsing any Java-based technology for application development. Although myriad frameworks are compatible, it’s wise to:

• Capitalize on known frameworks (like Spring MVC or Python development services).
• Opt for frameworks suiting project needs.
• For dilemmas, select the uncomplicated option.

Various frameworks, such as GWT and Vaadin, encompass their unique JavaScript to foster interactions. Despite the extensive range, Liferay, since its 6th version, introduced Alloy UI.

Rooted in YUI 3, Alloy UI brings forth contemporary UI components. Liferay’s core portlets employ Alloy UI, but developers have the liberty to pick any JavaScript library.

Liferay’s Service Builder is another feather in its cap. It eases the creation of interfaces and classes for database persistence and service layers.

By automating routine codes, it shifts focus to designing services’ higher aspects. Wrapping up, while Liferay recommends certain tools, it doesn’t mandate them. It’s the developer’s prerogative to pick the tools ensuring project success.