Developing effective portlets

Portlet development involves strategic planning and foresight. In NexJ CRM, portlet communication is facilitated through the context and event buses, rather than direct references to application controllers and individual forms. As such, both first and third-party portlets are able to be placed in different workspaces throughout the application without significant modification or redevelopment.

Building portlets that comply with portal infrastructure can maximize the efficiency and versatility of your NexJ
application. Portlet functionality should be compatible with all elements of the NexJ Framework and refrain from being
restricted to a single workspace.

Developing effective portlets involves three primary considerations:

Portal development best practices

Portal development best practices provide high-level guidelines on how to create an effective portlet. Following these conventions can improve development efficiency and network performance.

The portal development strategy consists of the following principles:

Portalized applications consist of one or more workspaces. Each workspace should contain multiple portlets that each perform a single primary function. Each portlet screen should have only one form inside it.
Portlets are developed independent from one another and operate in their own containers. They should communicate using only the context and event buses. Portlets are able to interact using the buses if they subscribe to the variables or events in their respective context or event attributes.
Inter-portlet refresh events are required to synchronize data across the application. The system event sysNotifyCommitSuccess is fired on all portlets that subscribe to it whenever an event has been committed. This ensures all user interfaces are up to date.

Example portalized screen

The following example demonstrates a NexJ CRM workspace synchronizing data by passing context variables through the context bus:

Three portlets in one workspace communicating through the context bus

When a contact is selected from the EntityNavigatorPortlet portlet on the left, the new value of the context variable is set and passed to the EntityDashboardPortlet and EntityJournalPortlet portlets on the right. They receive the updated string value of the variable and proceed to display the selected contact's information.

Portlet output

Portlets output information to communicate and interact with other elements of the application.

By passing context variables and UI Event notifications, user actions in one portlet can directly influence the behavior of others that exist in different containers. Outputting information using the buses allows NexJ CRM to provide a connected and functional interface to end users without compromising portlet versatility.

Portlets pass information within their own workspace using the context bus. String values of context variables are set and passed to all portlets in the workspace when the user has committed a change. This process is automated by the NexJ Framework using the sysContext system event. If a portlet subscribes to a context variable, it will automatically pass the value of the updated variable through the context bus when a change has been committed.

The event bus is used to output information to portlets that are not located in the same workspace. When a user performs an event, which can include using a button or checkbox, the associated UI Event will be fired through the event bus to notify all portlets listening for updates that it has been triggered. How the notification is handled will be determined independently by the receiving portlet.

Portlet input

Portlets input information to trigger data synchronizing actions.

Portlets react to changes that have occurred outside of themselves by receiving updates from the context and event buses. Although developed independently and stored in different containers, portal infrastructure allows portlets to be notified of all user actions through context variables and UI Event notifications. Portlets are able to interact with elements of the NexJ application regardless of the workspace they reside in if the same variables and events are persistently used.

When changes have been made to a context variable that a portlet subscribes to, it will receive the new value using the sysContext system event. The string value of the context variable will be retrieved from the context bus and the where clause of the activeNode will be re-queried to refresh and update the user interface. Each time a change has been committed this process immediately occurs.

Portlets receive UI Event notifications when events have been committed and broadcast from elsewhere in the application. Each portlet listening for the occurrence of events will individually determine how to react using an initialization script. Common handlers used to respond to notifications from the event bus can include refreshing the user interface or disabling elements of the portlet.

Portlet compatibility with your NexJ application

All portlets in your NexJ application should use common context variables and UI Events. This will ensure portlets are capable of interacting with each other and can be placed in more than one workspace if their functionality needs to be duplicated.

UI Events used in your NexJ deployment can be identified using NexJ Studio. In the Presentation layer, the UI Events tab provides a list of all registered UI Events. Context variables, however, are not stored or listed in NexJ Studio. Instead, developers are to manually keep track of the variables being used in NexJ CRM. Establishing a set of context variables and implementing them throughout the application is fundamental to the portalization process and necessary to use the NexJ Framework to its fullest potential.

Creating portlets that are compatible throughout the application requires a specific development approach. Portlets should not contain more than one form per screen. If multiple forms are contained in a single portlet, its functionality can only operate as a single unit; individual functions cannot be separated or used outside of that workspace without additional development and revision. Building portlets with multiple forms and functions in a single container hinders its adaptability by limiting the reuse of code and communication with other elements of the NexJ application.

Each portlet should perform one primary function. The source and target of context should be thought about in terms of a planned workspace, however, not restricted to it. Open and adaptable portlets should always be created before interconnected workspace screens with multiple forms.

Developing effective portlets

Related links

Portal development best practices

Example portalized screen

Portlet output

Related links

Portlet input

Related links

Portlet compatibility with your NexJ application