The following topics describe the core Presentation layer elements, and provide information on their naming conventions. Maintaining these conventions aids in model consistency and clarity. Additionally, it facilitates model maintenance and customization.

Applications

An application is a collection of screens.
Application configurations include specifying a caption, a description, an icon, a stylesheet, a menu, and a toolbar. Applications also specify a list of fixed screens and the initial screen.

Screens

Screens collect and lay out forms, controls, and sub-layouts. Screen names use camelcase capitalization with an initial capital letter and end with a suffix based on the screen type. For example, a command screen might have the name AllReportCommand.

The following table lists the screen types you can create in the Screens tab. The Format column provides a name template for the screen type. The italicized portion of the format represents the variable part of the screen name. The non-italicized portion should remain standard for all screens of the given type.

Presentation layer screen naming convention

Screen type	Purpose	Format	Example
Command	Displays configurable parameters.	<Name>Command	AllReportCommand
Create	Creates a business class instance for persisting in the application.	<Name>Create	CompanyCreate
Picker	Displays a list of objects that can be associated with a given class instance.	<Name>Picker	EntityPicker
Portlet	Defines the screen as a portlet, which can be added to a workspace.	<Name>Portlet	ImportProcessPortlet
Properties	Displays properties of a business class instance, which a user may choose to modify.	<Name>Properties	TaskProperties

Forms

Forms contain user interface controls to display data for querying, viewing, creating, or editing class instances. Forms contain a root layout of controls and optional additional sub-layouts. Form names use camelcase capitalization with an initial capital letter and ending with a suffix based on the form type. For example, a detail form might have the name TaskDetail.

The following table lists the form types you can create in the Forms tab. The Format column provides a name template for the screen type. The italicized portion of the format represents the variable part of the form name. The non-italicized portion should remain standard for all forms of the given type.

Presentation layer form naming convention

Form	Purpose	Format	Example
Detail	Displays the details of a single object for viewing or editing.	<Name>Detail	TaskDetail
List	Displays a collection of objects, typically the results of a query.	<Name>List	EntityList
Query	Provides the parameters used for a search.	<Name>Search	DocumentMgrSearch

Layouts

Layouts manage the arrangement of UI controls within a form or screen. Layout names begin with a prefix based on the screen type and use camelcase capitalization with an initial lowercase letter. For example, a caption layout might be named capWorkQueues.

The following table lists the layout types available in the Screens and Forms tabs. The Format column provides a name template for the layout type. The italicized portion of the format represents the variable part of the layout name.
The non-italicized portion should remain standard for all layouts of the given type.

Presentation layer layout naming convention

Layout type	Purpose	Format	Example
CaptionLayout	Appears at the top of its parent layout. Typically used to display a summary of the information from other parts of the parent layout.	cap<Name>	capWorkQueues
GroupLayout	Displays a collection of zero or more sub-layouts (group, splitter, or table) where only one sub-layout is visible at a time.	grp<Name>	grpEntityTelcoms
GroupLayout Tabs	Displays each sub-layout within a GroupLayout.	tab<Name>	tabDetails
SplitterLayout	Displays a collection of one or more splitter zones separated by a slider (horizontal or vertical), allowing users to resize the zone.	splt<Name>	spltRootLayout
TableLayout	Partitions an area into columns and rows.	tbl<Name>	tblEntitySearch

UI events

A UI event is a notification object that communicates context information associated with a user interface event, such as when a user clicks a button or selects a menu item. You can override the default framework behavior of UI events
by writing custom business logic in a UI action.

For more information about the properties of UI events, see UI Events.

External reports

An external report is the definition of a specific data report included in your application. External reports are created using the JasperReports Library, which is an open source reporting engine used to transform dynamic content into page-oriented, ready-to-print documents. NexJ Model Engine extends JasperReports functionality to query directly against a NexJ CRM business model. Reports are evaluated against the business model data at run time.

For more information about external reports, see Creating external reports.

Stylesheets and styles

Stylesheets specify how user interface elements look in NexJ applications. Stylesheets are collections of styles. A style specifies colors, fonts, borders, and other visual elements that affect how controls look.

The following sections describe the naming conventions and properties for stylesheets and styles:

Stylesheets

Stylesheets do not have a strict naming convention. However, it is useful to give stylesheets a descriptive name, for example, naming the default stylesheet for an application DefaultControls, and the stylesheet for the tablet application DefaultControlsTablet. Use camelcase capitalization with an initial capital letter to name stylesheets.

You can base stylesheets on other stylesheets. A child stylesheet inherits its propeties from the parent stylesheet on which it is based. For example, if the DefaultControls stylesheet uses the font Verdana-regular-8, basing a
new stylesheet on DefaultControls sets the new stylesheet's font to Verdana-regular-8. You can then customize the new stylesheet's properties. This method is useful for quickly creating stylesheets that are variants of existing stylesheets.

Styles

You typically create two types of styles for each control: a base style and state-specific styles.

Base style
Base styles determine how controls normally look. For example, the base style for buttons is called Button.

State style
State styles determine how controls look when the control's state is modified. For example, the Button-pressed style indicates how a button looks when clicked by a user. State styles are typically based on a base style, but have one or more properties modified to change their appearance. For example, the Button-disabled style is based on the Button style, but specifies a different color to distinguish disabled buttons from normal buttons.

Name styles to indicate the controls they apply to. For example, name a style Input to indicate that it applies to input fields. Use camelcase capitalization with an initial capital letter to name styles.

Name state styles using the format <Control>-<state>, where <Control> is the name of the base style, written using camelcase, and state is the control's state, written in lowercase. For example, name the style for disabled input fields
Input-disabled.

You can include custom CSS in styles to provide additional styling for controls. This is useful when you want to specify style properties that are not otherwise available. To add custom CSS to a style, enter the CSS text in the style's Extra CSS field.

Info

Text entered in the Extra CSS field must be valid CSS, and must not conflict with any properties already specified in the style. If the extra CSS does conflict with a property, the resulting style might not render predictably.

Colors

A colorsheet is a collection of named colors for use by stylesheets. This provides a single place for consistent, system-wide modification of an application's color scheme.

Icons

An icon is an image file, typically PNG format, that is used in user interface controls to provide an end-user with a quick, intuitive representation of an application function.

Controls

Controls provide the most granular user interface functionality within a screen or a form.

Control names begin with a prefix based on the control type and use camelcase capitalization with a generally lowercase initial letter. For example, a button control might be named btnTypeSelect.

The following table lists the controls available for use in the Screens and Forms tabs. Note that the Format column illustrates the format that should be used in naming controls. The italicized portion of the format represents the name of the control, which changes for every control. The non-italicized portion of the format specifies the layout type.

Presentation layer control naming convention

Control	Purpose	Format	Example
BarChart	Creates a bar chart for collecting and displaying user data.	bar<Name>	barCampaignParticipant StatusChart
Browser	Embeds a web browser.	browse<Name>	browseWebsite
Button	Triggers a UI event when clicked.	btn<Name>	btnTypeSelect
Calendar	Displays a small calendar.	call<Name>	calBusiness
Checkbox	Creates a selection box that takes on a value of #t when selected and #f when cleared. If tristate checkboxes are enabled, it is also possible to return a third state, with the value of null.	chk<Name>	chkActive
Combo	Creates an entry field in which a user can type or select one of a list of possible values.	cbo<Name>	cboHouseholdRole
CustomControl	The use of CustomControl varies for each instance. The naming convention of the control type CustomControl differs from the other controls. However, the name should start with a lowercase word followed by an uppercase format; for example, transactionHistoryChart.
Grid	Presents a set of records as clickable rows of data. Used along with GridColumns, it can create tabular data displays. Each row of a grid can be selected individually. In addition, you can add a multiselect tristate parent checkbox to enable the user to select multiple rows in a grid. The parent checkbox takes on a value of #t when selected, #f when cleared, and null when any child checkboxes have been selected individually. For example, when a user selects the parent checkbox and then clears one or more child checkboxes or when a user clears the parent checkbox and then selects one or more child checkboxes.	grd<Name>	grdClientStmtAccts
GridColumn	Contained within a grid. Allows a grid row to display additional attributes for each record.	col<Name>	colRegTypeName
HTMLLabel	Displays a label in an HTML format.	HTML<Name>	HTMLLicense
Image	Displays an image.	img<Name>	imgCompany
Input	Creates a single or multiline text entry field.	inp<Name>	inpEditTime
Label	Displays text, text and icons, icons only, or collections.	lbl<Name>	lblDashboardIcon
Menu	Displays a collection of MenuItems and separators as items in a pull-down menu. Compare with Toolbox, which displays the items as buttons in a horizontal bar.	mnu<Name>	mnuMainAppToolbar
MenuItem	Displays one of the items that will be displayed in a menu or toolbox. Menu items can have other menu items as children, which creates a cascading menu. Menu items without children will trigger a UI event when selected.	mit<Name>	mitSave
LineChart	Displays a collection of related data sets using a line chart visualization.	line<Name>	lineStatusChart
Picker	Creates a button that launches a popup. Commonly used to launch more complex selection screens.	pick<Name>	pickViewPrincipal
PieChart	Displays a collection of related data sets using a ine chart visualization.	pie<Name>	pieAssetChart
Previewer	Displays a preview of any attachments. Can also be used for uploading attachments.	prev<Name>	prevPortalAttachment
Schedule	Displays a schedule.	sched<Name>	schedContact
Toolbox	A specialized case of menu. Toolboxes display a collection of MenuItems as buttons in a horizontal bar. Compare with Menu, which displays items in a pull-down menu.	tbx<Name>	tbxEdit
Tree	Displays a tree-based navigation view of hierarchical information.	tree<Name>	treeHierarchy

Popups

Popups are modal dialogs that trigger UI actions. They are launched when users click a related picker control. Popup names use camelcase capitalization with an initial capital letter and end with a suffix based on the popup type. For example, a properties popup might have the name CampaignParticipantProperties.

The following table lists the layout types available in the Presentation layer. The Format column provides a name template for the popup type. The italicized portion of the format represents the variable part of the popup name. The non-italicized portion should remain standard for all popups of the given type.

Presentation layer popup naming convention

Popup type	Purpose	Format	Example
Create	Class creation dialog.	`Classname`Create	HouseholdCreate
Properties	Detailed edit dialog.	`Classname`Properties	CampaignParticipant Properties
Picker	Associated collection editing dialog.	`Classname`Picker	EntityParticipantPicker

Form and portlet references

Form and portlet references embed forms and portlets within a screen of the application. Form and portlet reference names begin with a prefix based on the type of object being referenced, followed by the name of the referenced object. The result of this concatenation is a name using camelcase capitalization with a lowercase initial letter. For example, a form reference to the TrnEntityList form would have the name frmTrnEntityList.

The following table lists the reference types that you can include on a screen. Note that the Format column illustrates the format that should be used in naming references. The italicized portion of the format represents the name, which changes for every reference. The non-italicized portion of the format specifies the reference type.

Presentation layer screen reference naming convention

Reference	Purpose	Format	Example
FormRef	Use when you want to include a form. The form reference should be associated with the form specified in the second part of the reference.	frm<FormName>	frmTrnEntityList
PortletRef Use	Use when you want to include a portlet. The portlet reference should be associated with the portletenabled screen specified in the second part of the reference.	ref<ScreenName>	refEntityNavigatorPortlet
PortletLayoutRef

Portal containers

Portal containers provide the architecture that allows you to create user interfaces to display or collect information.

NexJ CRM applications contain one or more workspaces. Each workspace will consist of portlets that contain elements which should follow standardized naming conventions.

The following table lists the elements of NexJ CRM that you will create and name. The Format column provides a name template for the element type. The italicized portion of the format represents the variable part of the name. The non-italicized portion should remain standard for all elements.

Portal container naming convention

NexJ CRM element	Purpose	Format	Example
Context variable	Provides a mechanism for changes in one portlet in a workspace to be reflected in others in the same workspace.	<ClassName>Id	EntityId
Docked workspaces	Enables instances of active workspaces to be minimized on the NexJ application toolbar for later use in their current state.	Docked<ClassName>	DockedEntity
Global properties variable	Provides a mechanism for sharing the value of variables between portlets belonging to different workspaces.	ClassName (camel case)	ContactListSearchContext

Presentation layer elements and naming conventions