JS extended portlets entry point - liferay/liferay-js-toolkit GitHub Wiki

:warning: The contents of this wiki have been migrated to the liferay/liferay-frontend-projects monorepo and more specifically to the to the maintenance/projects/js-toolkit/docs directory. Development and updates will continue there, and this repo will be archived (ie. switched to read-only mode).

---

Since the introduction of the create-jar option in the bundler, the developer can write pure Javascript portlets that are bootstrapped by the JS Portlet Extender in the server.

This document describes the contract between the JS Portlet Extender and the portlet.

Once the extender detects a JS-extended portlet, it looks for its main entry of package.json and imports that module assuming that it exports (as default) a function with the following signature:

function entryPoint({
  configuration,
  contextPath,
  portletElementId,
  portletNamespace
}) {
  // function body
}

As shown, the function receives a single object with several fields:

• configuration [since JS Portlet Extender 1.1.0]: this field contains the system (OSGi) and portlet instance (preferences as described in the Portlet spec) configuration associated to the portlet. It has two subfields:
  • system: contains the system level configuration (defined in Control Panel > System Settings)
  • portletInstance: contains the per-portlet configuration (defined in the Configuration menu option of the portlet)

👀 Note that all values are received as strings, no matter what their underlying type is in the definition.

• contextPath: the path to the web context of the module to be able to download static resources. It does not contain server, protocol or port parts, just the path portion of the URL (i.e. something like /o/my-portlet).
• portletElementId: the id of the DOM node where the portlet's UI must be rendered.
• portletNamespace: the portlet namespace as defined in the portlet specification.