Understanding DataSource Architecture
Every Centralpoint DataSource consists of four distinct components that must work together. Understanding this architecture is critical to building effective DataSources.
| Component |
Purpose |
Location in Admin |
| SQL SELECT Command |
Retrieves data from the database |
DataSource → SQL tab |
| Template Content (Header) |
Wrapper HTML, table structure, scripts, registrations |
DataSource → Template tab |
| Item Content |
Repeating row/card template for each record |
DataSource → Item tab |
| Styles (CSS) |
Visual styling (prefer embedding in Template) |
DataSource → Styles tab |
Additionally, there is an Empty Item Content section for displaying a message when no records are found.
Critical Rules for DataSources
Rule 1: The Placeholder Requirement
The Template Content MUST include this exact placeholder or rows will NOT render:
[cp:placeholders key='ItemContent' /]
❌ WRONG: [cp:ItemContent] — This will cause rows to silently fail
✅ CORRECT: [cp:placeholders key='ItemContent' /]
If rows are not displaying, check this FIRST.
Rule 2: Attributes vs. Standard Fields — THE MOST IMPORTANT DISTINCTION
Most fields are actual database columns, but some are Custom Attributes or XQueries added to the Module Configuration. These will NOT be found directly in the SELECT command.
Attributes need to be called differently:
- In SQL: They come from
cpsys_DataCurrent.Attributes (included via JOIN)
- In Item Content: Use
cpsys_Attributes:NameOfField NOT simply NameOfField
They will NOT render unless you call them correctly.
How to Reference Each Field Type
| Field Type |
In SQL SELECT |
In Item Content (cp:scripting) |
| Standard Fields |
cprel_ModuleName.[FieldName] AS [FieldName] |
name='FieldName' |
| Attributes (Custom/XQuery) |
Included via cpsys_DataCurrent.Attributes JOIN |
name='cpsys_Attributes:FieldName' |
Rule 3: Embed CSS in Template Content
Prefer embedding styles within <style> tags inside the Template Content rather than using the separate Styles field. This keeps the DataSource compartmentalized and prevents CSS from leaking out to other page components.
Rule 4: No Server Module Tags
NEVER use module:* server tags in DataSource templates — they cause ASP.NET compilation errors.
Rule 5: ALWAYS Include Commented cp:scripting Patterns in SQL
The SQL SELECT command should include ALL potential cp:scripting filter patterns, even if commented out with the // prefix. This preserves the DataSource's flexibility — developers can simply uncomment the patterns they need rather than having to look up or recreate the syntax.
The // prefix comments out a cp:scripting tag — it remains in the code as a reference but does not execute.
Rule 6: Double-Check Field Types Before Rendering
Always verify whether a field is a standard field or an attribute. Use the appropriate cp:scripting syntax based on the field type. They will NOT render if called incorrectly.