Skip to content

Domain Knowledge Model

Jump to bottom
hilaire edited this page Dec 7, 2025 · 8 revisions

General principle

Internal architecture

  • A DKM depends on the DKM-Core package, it provided the abstract class DKMPresenter.
  • A DKM should be implemented with the MVP pattern (Model-View-Presenter)

Technical TODO

Describe the technical structure of a DKM in the Host system, particularly its files organization.

  • Directory nomenclature per teaching domains, topics. For example, Physics/Thermodynamic/GasSimulation, Mathematics/Geometry/InteractiveGeometry.
  • One DKM, one Cuis package
  • Each DKM is in its own directory with its related data:
Physics/Thermodynamic/GasSimulation/
   GasSimulation.pck.st
   version
   i18n/locale/fr/LC_MESSAGES/GasSimulation.mo
   i18n/po/GasSimulation.pot
   i18n/po/fr.po
  • A DKM may depends on one or more CuisFrench.pck.st, CuisSpanish.pck.st packages to provide user programming with localized messages and classes. The localized versions of the messages specific to the DKM itself must be provided in the DKM package itself, in a dedicated category or subclass of its Presenter class. (i.e. DSL-French, DSL-Spanish, etc.).
  • The version file informs the version of the DKM DSL. Better in the form of a date stamp 2025-12-07. Its objective is to ensure compatibility between user script and a DKM package. Version number should increase only when the DKM DSL has incompatible changes.
  • When the user first starts its DyboApp environment, it installs the DKM he wants to use. The DKMs are installed from theirs respective directory.

Clone this wiki locally