A typical R&D implementation of a window, here frmCompanyInfo, uses the base class cFormWindow and implements fields and business logic.
Client customizations in IFS Applications 9 are based on the visual form inheritance that is built in as standard concept in the .NET language. Visual Studio provides all the necessary features and language syntax making it possible to create customized form that are using the R&D developed windows as base, only having to add or change whatever is necessary, keeping the rest as standard.
Apart from customizing existing windows, there’s also possible to create brand new windows being based on standard Foundation1 class templates, exactly as done in earlier versions of IFS Applications.
Above mentioned scenarios, customizing existing windows and/or create new windows as part of a customization, will result in source code and assemblies that are contained in separate "layers" that are totally separated from the source code and assemblies that are delivered from R&D, which is the "Core" layer.
In IFS Applications 9, there are three layers you can work with: Core, Ext & Cust.
This is the layer that is delivered from R&D containing all application logic. It can't be edited and is used as template for the other two layers, Ext or Cust. These layers can they override proper methods and by that change the standard Core implementation.
This layer is the first layer that can be chosen, after the Core, and is meant to be used for all extensions of IFS Applications 9. Typically, R&D development that is made as request from several customers that in the future will be merged into the core product of IFS Applications, is an extension. This layer may use window templates as base from the Core layer only.
This layer is the second (and currently the last) layer used to customize windows after
requests from single customers. This layer may use window templates as base from
both the Core and/or Ext layers.
A typical R&D implementation of a window, here frmCompanyInfo, uses the base class cFormWindow and implements fields and business logic.
A customization of frmCompanyInfo uses the very same as base class for the customized window frmCompanyInfo_Cust, where all the necessary changes are made.
.
Extensions and/or Customizations are separated from the Core implementation and compiled into its corresponding assemblies. These assemblies will in turn be deployed on the same place that the Core assemblies are located -> the DeployFiles folder (the folder containing all the runtime files).
The layer name is used to make each assembly unique and is therefore appended as suffix.
Customizing the assemblies in the Enterp component may result in the following assemblies and naming:
A huge advantage here is having the possibility to deliver Update deliveries in to the Core layer (from R&D) and then only having to re-compile the customizations in the Ext and/or Cust layer in order to have everything ready for testing. Not being forced to "lift" every patch by merging it into the existing source code with its customization will result in an improved delivery lead-time from R&D to customer.
Similar as for Assemblies, the navigator xml files where you define the nodes for windows that should be possible to navigate to from the navigator, each layer will have its own navigator xml for that purpose:
Customized windows (windows being extended based on existing Core windows)
have normally no need in changing the navigator since they will be available
thanks to the dispatch mechanism that replaces the URL's with original windows
with customized windows.
New windows on the other hand, developed being part of the customization, might
have the need to be placed in the existing navigator. Here's when the layered
xml files come in handy, separating Core and customized navigator entries. Upon
a client build, all the navigator xml files will be merged into one, forming the
total navigator and its nodes.
