Verne Module
A Verne Module is a collection of functionality, that combined make up a functional ‘something’ within Verne. Amongst all of the functionality are the configuration files, that you, as a Configurator would see under a directory structure called vfs.
There are lots of modules, and they conform loosely to a couple of different types, with their content pretty much defining what type of module they actually are. Don’t get too hung up on the ‘type’ – it is just a way to try and manage all of the functionality in some form of logical collection.
Consideration One – Verne Consolidates the ‘Layers’ that the Modules Represents
Verne looks at all of the modules that are used to build the register and applies a hierarchy within these modules. The hierarchy is important, as it provides the way for a Configurator to use all the good stuff that a module gives, but to also override the bits that it needs to.
Consideration Two – As a Configurator, you Define how Verne Establishes Hierarchy
Following on from the point above. It may be apparent to us that module-a is effectively the baseline module, and module-b sits above it (or below it, depending on how you look at it), but Verne doesn’t know – it needs to be told. And you get the job of doing that in your application.xml configuration files – more of that shortly.
Consideration Three – Watch out for ‘Conflict’
Verne doesn’t know which modules may get defined in your hierarchy, so it does not attempt to ‘police’ the configuration data that you define with respect to any other module. What this means in practical terms is that you may get duplicate, or in fact, conflicting information.
Imagine that in verne-core you defined a Domain that had an attribute called Date Of Birth, but in your ‘business-specific’ module you omitted it because the register you are building doesn’t need it. Do you get the Date Of Birth attribute included in your final register or not?
Well, there are rules, and these rules are defined for each file within the vfs. The rules are documented below, and they appear in a section called Merge Strategy in each Configuration in Detail page.
How Verne Builds The Hierarchy
Having decided that the register is to be built out of a whole load of modules, Verne uses the information within these modules to establish the hierarchy of module ‘layers’. To do this, there are a few commands that it uses, and these should be appreciated for what they are.
RequiresCode and ExtendsCode
These are two configuration elements that feature in the application.xml for each module that is to be used to build the register. We’ll look at some ‘real-life’ examples of this file in the next section.
The first thing to appreciate is that there is not really a distinction worth bothering too much about when it comes to these two elements. There are two because that’s the way Verne evolved, and if you specify the wrong one, Verne will generate an error telling you, and then all you do is change them around.
What they both do, however, is to establish the ‘baseline’ modules that are to be brought in to support the particular module that the application.xml file is associated with. To make sure we are all looking at this the same way, a ‘baseline’ module will mean that it sits at the bottom of the pile, and is a predecessor (this term is used in merge strategies, so remember it) to the module that sits above it.
