AFL portlets and controls let you work directly with JavaScript, CSS, and HTML. They leverage AFL core libraries for portal lifecycle management, data binding, context bus management, control development, internationalization and more.

Portlets

A portlet is a UI view (control) that can contain child controls and supports the portal bus. With AFL portlets, you can build any portlet pattern provided by MDA portlets (lists, details, charts, and so on), but since you are simply working with JavaScript, CSS, and JavaScript libraries, you have more flexibility to implement less common patterns.

An AFL portlet is really just a module that returns a portlet control that, in turn, typically contains a card control, with logic, and bindings, and other controls.

return function() { 
	return ui("Portlet", {children: [ui("Card", {...
};

AFL portlets are typically saved in mod/app/<portletName>.js and are available at <server-root>/ui/<portletName>. Any CSS rules specific to the portlet are saved alongside the module in mod/app/<portletName>.css.

Controls

AFL controls are modules that contain a view definition (properties, behaviors) and a renderer to generate the control's HTML, CSS, and JavaScript. Renderers may use AFL libraries or React. The AFL core libraries contain a rich set of pre-built controls (many are in the `nexj/ui` and `nexj/ui/core` modules). If you have the demo app running, try looking at http://localhost:7080/training/ui/demo for examples of some of the pre-built controls. You will see charts, cards, tabs, and complex composite controls like the schedule.

AFL portlets and control definitions are simply modules. The following section discusses their structure. 

Module structure

Modules begin with their name and a list of dependencies. The module dependency system is based on the Asynchronous Module Definition (AMD) specification.

/** Sample Module */ 
define("app/mysample", ["nexj/sys", "nexj/ui", "nexj/ui/core", "nexj/ui/obj", "nexj/ui/bus"], 
	function(sys, ui) {"use strict"; 
		return function() { 
			return ui("Portlet", {children: [ui("Card", {...
		};
	}
);

A module always contains the define(); function. It takes three parameters:

• The module name, for example, "app/mysample" (must match the file name of the module in your project's mod folder. "/" in the name represents either the folder structure or a "." in the name).

• Dependencies, which is a list of modules and module mix-ins that this one depends on

• A function that takes the dependent modules as parameters and returns a function that returns a view (typically a portlet for portlet modules).

In this example, the module name is "app/mysample" and the module should be saved in the mod/app/mysample.js file.

The dependencies are ["nexj/sys", "nexj/ui", "nexj/ui/core", "nexj/ui/obj", "nexj/ui/bus"]

The function takes sys and ui as parameters which map to the contents returned from "nexj/sys", "nexj/ui". The other dependent modules are mix-in extensions for these three modules. The function returns a function that returns a ui("Portlet", ... object. This portlet object has some layout properties and a collection of child controls.

These controls, in turn, have their own module definitions with a view definition and a renderer. These are maintained in separate files by convention. The typical arrangement is:

• mod/nexj/ui.mySampleControl.js - where the control's view is maintained. This includes the control's properties and behaviors.
• mod/nexj/ui.mySampleControl.dom.js - where the control's renderer is maintained. A control's renderer can be coded using:
  

  • The AFL dom renderer which uses JSONML for the layout,

  • Or the AFL React renderer, which allows you to write your rendering, and most of your control, in React.

• mod/nexj/ui.mySampleControl.css - where any control-specific css rules are maintained