Page History

The HTML rendering the UI conforms to the basic layout using a table of class widget grid.

The HTML rendering the UI uses only the defined CSS classes.

The UI conforms to the basic guidelines.

The UI uses the widgets supported by the XperienCentral platform.

The JSPs that render the HTML use the JSTL tags and JSP tags offered by the XperienCentral platform as often as possible.

The UI conforms to the defined UI interaction patterns.

The business object is implemented as a POJO and does not contain any reference to a controller, form backing object or DAO.

The business object does not contain properties or logic whose sole purpose is the view.

The FormBackingObject is implemented as a POJO and does not have any reference to a controller, DAO or business object unless the business object is a POJO itself.

The FormBackingObject reflects the properties and logic to be rendered by the view and not the properties and logic of the business object from which it retrieves values.

The FormBackingObject and Business Object is not one and the same object.

The copyProperties() method of org.springframework.beans.BeanUtils is used to transfer values from the FormBackingObject to the business object (or vice versa).

The controller is a separate class and implements all controller logic.

Persistence logic is not contained by the business object but implemented in a separate DAO.

JSPs do not contain SQL statements or other persistence implementation-specific logic unless they are contained by a separate JSP tag.

The plugin contains all resources not provided by dependencies or other presentation plugins and is capable of being deployed and functioning properly on any XperienCentral installation, as long as all its defined dependencies are available.

The version number of a plugin conforms to the syntax "major.minor.micro".

The version numbers of the plugin are independent of the XperienCentral release they were developed for.

If the datamodel of the plugin has been changed in a newer version of the plugin , the plugin must properly handle datamodel updates.

The API that XperienCentral provides is used to access the data model XperienCentral exposes.

XperienCentral features and API functions are used where possible instead of implementing custom functions.

When the plugin uses a service, a dependency with that service is defined in the component definition in order to retrieve a reference to the service.

Text, images and other GUI components are suitable for translation.

Multilingual content that can be created using the plugin is translatable.

Language labels are defined in language resource files conforming to JavaI18N and the filename meets the syntax messages_<language>_<country>_<variant>.properties.

Label IDs in the language resource files use only lower case letters.

Language labels in language resource files are grouped per component and prefixed with at least the ID of the component.

Documentation is available in at least the US English language.

A plugin is distributed as a single ZIP file known as a WCA (WebManager Component Archive) which can also contain other related plugins.

The contents of the WCA conforms to the defined directory structure.

The WCA contains a readme.txt and a changelog.txt.

The layout of the the readme.txt and and changelog.txt follow the defined templates. Click the links to the left to download the templates.

The plugin JAR file containing the software follows the defined directory structure.

The HTML generated by the JSPs for rendering the Editor is XHTML 1.0 transitional compliant.

All content generated by the plugin is stored in the JCR or in an external database if there is an obvious need for it.

The configuration management service is used to store configuration options. No hard-coded web IDs, paths or URLs are used in the software.

The preferences service is used to store all preferences.

The output-html-encoded-quotes XSLT template is used to properly escape HTML strings in the output when using XSLT.

SQL-prepared statements are used for all SQL queries.

At least one RBAC category is defined for each component which has a GUI representation which contains one or more RBAC permissions for the component.

A permission category defines and implements at least the RBAC permissions as defined.

The implementation of RBAC permission handling is mainly programmed in a controller or service, not in the business object itself. The check is only performed in the business object itself if the permission defines authorization to retrieve or update that particular property only.

The definition of all RBAC permissions is positive. Permissions are defined in a way that assigning the permission to a role grants the role particular rights and it never denies rights.

Coding conventions: the coding conventions that Sun publishes as the standard for the Java programming language are followed.

Coding conventions: Java language features are used where applicable (Java version 5 and higher).

Coding conventions: Java Util Logging is used where applicable and proper log levels are used (Java version 5 and higher).

Coding conventions: Java concurrency utilities are used where applicable (Java version 5 and higher).

Coding conventions: old collections like Hashtable, Vector or Dictionary are not used if it can be avoided.

Coding conventions: the @override annotation is used if a method is overridden from a super class.

Coding conventions: The basic variant of the Hungarian notation is used.

Coding conventions: The source code does not contain blank spaces before and after method arguments, however, spaces are used after Java keywords and commas.

Coding conventions: Declare variables and methods in the following order: Class (static) variables, instance variables, constructors, methods.

The FIXME comment is used to indicate that code snippets are incorrect during development and do not appear in a released plugin.

The TODO comment is used to indicate that code snippets are incomplete during development and do not appear in a released plugin.

Coding conventions: Spaces are used instead of tabs for trailing white space in the source code.

Coding conventions: The size of one line in the software code is limited to 120 characters.

Coding conventions: Start brackets are added on the same line as the statement to which they apply but ending brackets appear on a new line.

Coding conventions: Brackets are used in all cases, even for single line statements.

Coding conventions: The source code conforms to Javadoc conventions defined by Sun.

Coding conventions: Public and protected classes, interfaces, variables and methods are tagged with Javadoc.

The Javadoc does not contain references to documents that might not be accessible by external developers.

General plugin classes conform to the defined naming conventions.

Element component classes conform to the defined naming conventions.

Element component classes conform to the defined hierarchy.

Media Item component classes conform to the defined naming conventions.

Media Item component classes conform to the defined hierarchy.

Panel component classes conform to the defined naming conventions.

Panel component classes conform to the defined hierarchy.

The domain used for naming is returned by ComponentBundleDefinition.getDomain().

The plugin ID is returned by ComponentBundleDefinition.getWCBId().

The prefix equals the plugin ID.

Package names used in the source code of the plugin conform to the package naming guidelines as defined by the Sun coding conventions.

Top level Java package names follow the syntax <domain>.<plugin ID>.

The artifact ID in the pom.xml equals the plugin ID.

The group ID in the pom.xml equals the domain.

The ID of the component bundle definition defined in the activator of the plugin conforms to the defined syntax.

The ID of each component definition contained by the plugin must be prefixed with the component bundle definition ID followed by an ID that is unique within the plugin, matches the component name and consists of lower case alphanumeric characters in the range [a-z]. This does not include the media item component definition.

All IDs and properties defined use only lower case letters.

The name of the RBAC category conforms to the syntax  <top level domain>.<plugin ID>.<Component ID>.

The technical name of each RBAC permission is prefixed with the technical name of the RBAC category, followed by a dot.

Technical names of categories and permissions are in lower case, do not contain spaces and separate words are separated by a dot.

For CRUD actions, the defined naming conventions are used.

In user documentation, the defined naming conventions are used for XperienCentral assets.

All names of labels, Java classes, methods, properties, etc. are in US English unless they represent translatable labels presented to the end user.

The CMU-SEI (https://en.wikipedia.org/wiki/Cyclomatic_complexity) does not exceed 15.

Online help covering the visible components contained by the plugin is available.

An API is exposed by a domain object interface when it consists of getters and setters for properties of that domain object.

Implementations of a domain object interface is postfixed with "Impl".

An API is exposed as a service when the API creates or deletes domain objects or operates on multiple domain objects.

An API service managing entities is preferably postfixed with "ManagementService".

A method handles an exception internally if it is recoverable.

A method throws a checked exception if it is unrecoverable and occurs in an area outside the immediate control of the program.

Identifiers used by a plugin are defined in one class as public static final fields of that class.

A plugin exposes its identifiers by exposing the class as defined by guideline G116.

Any class or interface that is exposed by a plugin as API should be contained by a package called "api" directly under the plugin's root package, or by a sub package of this package.

If content is stored in an internal relational database, the SQL scripts to create those database tables should be contained by the plugin in a /sqlscripts directory.

Each plugin should come with a unit test or test bundle that has a code coverage of at least 10%.

The plugin ID only contains alphanumeric characters in the range [a-z].

The domain only contains alphanumeric characters in the range [a-z] separated by dots.

In the JSPs, properly escaped strings in the HTML are output using standard JSTL functions.

The contenttype of a media item component which is defined by the @ContentType annotation must equal the plugin ID or be prefixed by the plugin ID and may only contain alphanumeric characters in the range [a-z].

Use the Entity Manager as the DAO implementation to store entities in the JCR when possible.

Creating and removing resources on which a plugin depends should be done automatically upon installation and purging the plugin if possible.

Framework labels are grouped separately in the language resource files.                           

Language files are at least available in US English.

A method should not catch an unchecked exception if it is unrecoverable and occurs in an area inside the immediate control of the program.

A new checked exception type is used as the wrapper for multiple checked exceptions if the amount of thrown checked exception exceeds five.

The Javadoc clearly explains how the class or interface should be used, preferably by providing code examples.

For each package contained by the plugin, a package.html is provided that clarifies the purpose and contents of the package.

HTML generated by the JSPs for rendering the website environment should be XHTML 1.0 transitional compliant.

If a method of a class implements a method of an interface, refer to the Javadoc of the interface using the {@inheritDoc} annotation.

The bundleSymbolicName in the pom.xml matches the syntax <domain>.<plugin ID>.

The presentation plugin is self-sufficient and does not depend on any resource provided by another plugin unless it is another presentation plugin .

JSPs copied from the original XperienCentral platform presentation are copied to the specified directory.

The value of the name attribute in the descriptor of a JSP is prefixed by the plugin ID.

Static files used by the presentation plugin are located in a subdirectory that equals the plugin ID.

The software does not contain code snippets that are commented out, not used or that duplicates of other code snippets in the same plugin .

Media item JSPs that display the content of a media item contain a check to see whether the media item has not already been rendered before within the same request.

Use the Link.linkAttributes() method to build links in a JSP.

Implement caching properly by providing SSIs.

A plugin contains only those components that logically belong to each other.

The plugin does not contain the empty online help that was generated by the archetype.

Do not use public or protected instance variables. Use private instance variables with getters and setters instead.

The plugin ID and domain are approved by GX and the plugin (of this version) is registered.

The name of a scheduled job is prefixed by the plugin ID.

The ID of each configuration set defined by the plugin is prefixed by or equals the plugin ID.

The plugin contains an example frontend presentation if it requires such a presentation to work properly.

The plugin supports the software and hardware as described in Hardware and Software Requirements.