Many of the things that we do during development in C/SIDE might not be called programming by some people as it doesn't involve writing C/AL code statements. However, so long as these activities contribute to the definition of the object and affect the processing that occurs, we'll include them in our broad definition of C/SIDE programming.

These activities include setting properties at the object and DataItem levels, creating Request pages in Reports, defining Controls and their properties, defining Report data structures and their properties, creating Source Expressions, defining Functions, and, of course, writing C/AL statements in all the places where we can put C/AL. We will focus on C/SIDE programming primarily as it relates to tables, reports, and codeunits.

We will touch on C/SIDE programming for pages and XMLports. In the case of RTC reports, C/AL statements can reside only in the components that are developed within the C/SIDE Report Designer and not within the RDLC created by Visual Studio.

NAV objects are generally consistent in structure. Most have some properties and triggers. Pages and Reports have controls, though the tools that define the controls in each are specific to the individual object type. Reports have a built-in DataItem looping logic. XMLports also have DataItem looping logic, but those are structured differently from reports; for example, Reports can have multiple DataItems at 0 level and XMLports can only have one Node at 0 level. All the object types that we are considering can contain C/AL code in one or more places. All of these can contain function definitions that can be called either internally or externally (if not marked as Local). Remember, good design practice says any functions designed as "library" or reusable functions that are called from a variety of objects should be placed in a Codeunit or, in some circumstances, in the primary table.