There is some general configuration that applies to nearly all products. See Gadgets for examples.
The top-level of the product instance typically provides navigation to the rest of the product. In many cases this will be a node of type Aggregator Package, with the aggregator layout field set to Icon Layout to show the next level of folders as icons. See Product folder customisation for instructions on how to use folder customisation to hold the configuration of your main folder in your product library.
The rest of the product structure will be a series of sub folders and nodes under the top-level folder. The application code will need to be able to identify these folders, so set the Bindings field on the main folder (look in the Advanced section) to identify the different parts of the application.
A typical application will require bindings for the following:
- The top-level product folder, using the reference "main".
- Each of the data folders, using a suitable data name.
- Each of the user groups, using a suitable name such as "users" and "administrators".
- If you are using managed permissions, the permission manifest manager, using the binding "permissionManifestManager" (see Product permissions).
If you have a large number of bindings, you can hold the bindings in a node of type Dynamic Bindings in the advanced settings folder and inherit from this in the top-level folder.
All products will need a folder containing the instance-level configuration, such as user and permission setup. This is typically called "Advanced settings" with a local reference of "advanced_settings". It can be hidden from users by putting it in a hidden section. Use the Stale Folder Listing type for advanced settings, as it prevents unnecessary triggering of recalculation. See Advanced settings in the sample.
Many products will also want some navigation panel. Setting up navigation can be a bit tricky, and usually the easiest way is to create a navigation script – see Gadgets Navigation Script for an example. Your top-level folder should inherit from the navigation script itself, though this can be done by folder customisation.
The navigation script returns a hierarchy of items. You can set a product-specific class on the top-level item to switch on your product theme. Look for the gadgets-navigation class in the getItems() method of the sample script.
Some nodes have code that is triggered to run on initialization. You can specify the order in which this code runs using an Initialization List. Give the list a name of "@init". put it directly under the main folder, and set the initialization list to the nodes that need to be initialized, in order. Also set the Delete on initialization option to remove the initialization list once it has done its work.
See @init for an example.
When creating a product, you may need variants of standard types, typically to add icons or body classes to modify the display. You can do this by copying the standard types but setting the Inherited copy option to link the definition of the copy to that of the original. You can then set or override icons, display properties, etc. For example, the role maintainer in the sample (used to assign users to roles) uses an inherited copy of the standard type and then sets a custom icon – see Role User Group Maintainer for details (look in the edit view).
See Product folder customisation for details of how to perform more extensive customisation of the standard folder types.