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.
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 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
|Create||Creates a business class|
instance for persisting in
|Picker||Displays a list of objects|
that can be associated with
a given class instance.
|Portlet||Defines the screen as a|
portlet, which can be added
to a workspace.
|Properties||Displays properties of a|
business class instance,
which a user may choose
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
|Detail||Displays the details of a|
single object for viewing or
|List||Displays a collection of|
objects, typically the results of a query.
|Query||Provides the parameters|
used for a search.
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
|CaptionLayout||Appears at the top of its|
parent layout. Typically
used to display a summary
of the information from
other parts of the parent
|GroupLayout||Displays a collection of|
zero or more sub-layouts
(group, splitter, or table)
where only one sub-layout
is visible at a time.
|GroupLayout Tabs||Displays each sub-layout|
within a GroupLayout.
|SplitterLayout||Displays a collection of|
one or more splitter zones
separated by a slider
(horizontal or vertical),
allowing users to resize the
|TableLayout||Partitions an area into|
columns and rows.
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.
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 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.
You typically create two types of styles for each control: a base style and state-specific styles.
Base styles determine how controls normally look. For example, the base style for buttons is called Button.
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
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.
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.
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.
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 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
|BarChart||Creates a bar chart for|
collecting and displaying
|Browser||Embeds a web browser.||browse<Name>||browseWebsite|
|Button||Triggers a UI event when|
|Calendar||Displays a small calendar.||call<Name>||calBusiness|
|Checkbox||Creates a selection box|
that takes on a value of
#t when selected and #f
If tristate checkboxes are
enabled, it is also possible
to return a third state, with
the value of null.
|Combo||Creates an entry field in|
which a user can type
or select one of a list of
The use of CustomControl varies for each instance.
The naming convention of the control type CustomControl differs from the other
|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.
|GridColumn||Contained within a grid.|
Allows a grid row to display
additional attributes for
|HTMLLabel||Displays a label in an|
|Image||Displays an image.||img<Name>||imgCompany|
|Input||Creates a single or multiline|
text entry field.
|Label||Displays text, text and|
icons, icons only, or
|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.
|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.
|LineChart||Displays a collection of|
related data sets using a line chart visualization.
|Picker||Creates a button that|
launches a popup.
Commonly used to launch
more complex selection
|PieChart||Displays a collection of|
related data sets using a ine chart visualization.
|Previewer||Displays a preview of any attachments. Can also be used for uploading|
|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.
|Tree||Displays a tree-based|
navigation view of
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
|Create||Class creation dialog.||HouseholdCreate|
|Properties||Detailed edit dialog.||CampaignParticipant|
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
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
|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.
|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.
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
|Docked workspaces||Enables instances of active workspaces to be|
minimized on the NexJ application toolbar for later
use in their current state.
|Global properties variable||Provides a mechanism for sharing the value of variables between portlets|
belonging to different workspaces.
|ClassName (camel case)||ContactListSearchContext|