ws-seo
Line 1: Line 1:
 
+
{{SEO
 +
|Title=Open CSP Class definition architecture
 +
|Keywords=OpenCSP,documentation,architecture
 +
|Description=The pages architecture within Open CSP explained.
 +
|Image=OCSP-Documentation.jpg
 +
|Image alt=Open CSP Documentation Banner
 +
|Section=Documention/Open_CSP
 +
|Published time=2023-10-01
 +
}}

Revision as of 20:21, 27 October 2023

Open CSP stores metadata of pages in slots. Pages are displayed with various components (for which the Chameleon skin is used), which can look differently based on the configuration found in class definition pages.

Metadata stored in slots

Before slots were used, there were two common ways to deal with structured data:

  • A) Have templates with structured data in between the content (free text) of a page.
  • B) Have one template that wraps the entire page content, with some parameters for structured data and also a parameter for free text

The advantage of using slots is that you can separate the metadata from the content and also separate the storing of the data from displaying it. This reduces the risk of making mistakes when editing, while allowing you to have forms for editing structured data and to use VisualEditor to edit the main content.

Note: data is stored in SMW properties as well, but class definitions do not rely on this. SMW is used for example for Search and Pages. It would technically be possible to modify the Open CSP framework to work with a different data storage extension, if you would make your own alternatives for the pages that use SMW queries or WikiSearch.

The following slots are used by Open CSP:

csp-base-props

In this slot Template:Base properties is used to store data dat is common to all pages, such as the Class and Title:

{{Base properties
|Class=
|Title=
}}

csp-class-props

In this slot Template:Csp class properties is used to store data that is specific to each class, based on the class definition:

{{Csp class properties
|Parameter1=Value1
|Parameter2=Value2
|...
}}

csp-data

This is a json slot which the framework only uses for class definition pages, but could be used for storing any json data on content pages as well (if you make your own templates/forms for this).

Example slots of a content page

Let's say we have a page about a person, this could have the following slots:

csp-base-props:

{{Base properties
|Class=Person
|Title=Example person
}}

csp-class-props:

{{Csp class properties
|First name=John
|Last name=Smith
|Date of birth=1986-03-16
}}

Example slots of a class definition page

To continue the previous example, a "Person" class definition page would have pagename Wiki:Class definition/Person and could have the following slots:

csp-base-props:

{{Base properties
|Class=Class definition
|Title=Person
}}

csp-class-props:

{{Csp class properties
|Defines class=Person
|Pagetitle format=title
|Layout areas='sub-header sidebar' 'main sidebar'
|Layout columns=3fr 1fr
|Layout rows=auto 1fr
}}

csp-data:

{
    "CspParameterDefinitions": [
        {
            "name": "First name",
        },
        {
            "name": "Last name",
        },
        {
            "name": "Date of birth",
            "formfieldTemplate": "Csp formfield/date",
            "displayTemplate": "Csp parameter display/date",
        }
    ]
}

Components

Open CSP uses the Chameleon skin to be able to display pages with customizable components. The following components are used:

  • Header: always visible at the top of a page
  • Main: this component displays the content that is stored in the main slot of a page, i.e. the text that is written by users
  • Sub-header: by default shown below the header with Template:Csp default subheader, can be customized through class definitions
  • Sidebar: by default shown on right side with Template:Csp default sidebar, can be customized through class definitions, metadata is displayed in this component
  • Footer: by default not displayed, can be customized through class definitions


Open CSP uses system messages inside these components. These system message contain some logic with various parser functions and Lua functions, in order to display a component based on the slot data of page as well as the slot data of the corresponding class definition page. This logic works as follows:

  • A component contains a system message that invokes a Lua function, for example {{#invoke:CspComponents|parseComponentIfApplicable|sidebar}}. This Lua function does the following:
  • Retrieve slotdata from current page
  • Get "Class" parameter from slotdata (return if it does not exist)
  • Get class definition pagename corresponding to the class
  • Get slotdata from class definition page (return if it does not exist)
  • If the component is not found in the "Layout areas" parameter of the class definition page, return
  • Parse component template (for example Template:Csp default sidebar, unless a different template is found in the class definition data)
  • Pass all of the slotdata from the current page as well as the class definition slotdata to this template, in the form of an ArrayFunctions export