MySource Matrix Developer

Main Content

MySource Matrix at a Glance

Information presented on this page is not an exercise. This is a summary of the information a trainer needs to go through with the trainee.

Concepts mentioned below and within the first tutorial ("Creating An Asset") are assumed to be covered for the exercises that follow (see the dropdown box above right)

System Architecture
  1. Checkout and install a Dev system
  2. Set up a simple site and experiment with a few assets

    • Standard Page
    • Asset Listing
    • Form
    • Show how content can be shared between two assets
  3. Basic concepts

    • Assets
    • Links
    • Permissions and statuses
  4. Matrix Code

    • File system structure
    • Important files - asset.inc, asset_manager.inc located in core/include
Asset Basics
  1. Anatomy

    • All asset's files have to be in a directory with the same name as the asset type
    • 3 inc files: TYPE.inc, TYPE_edit_fns.inc, TYPE_management.inc
    • asset.xml
    • screens
  2. Screens

    • Base asset defines a set of screens which are automatically available to other assets
    • to override a parent's screen the xml file has to be copied completely
    • to add a new screen (not known by the parent), it should be registered in the edit_interface_screens.xml file, which lets Matrix know about the new screen. see examples in code.
    • Functions looked up in TYPE_edit_fns.inc file
  3. Available attributes types, where to find them and how to use them
  4. Localisation

    • kept inside locale directories
    • screens

      • same structure as screen.xml files
      • if screen is called edit_interface_screen_details.xml, translation file should be called lang_screen_details.xml
      • inherit components from parents (unlike screens themselves)
      • changes to screen file structure require re-compilation of locales even if strings have not changed
    • strings

      • global, package and asset specific
      • kept in lang_strings.xml
      • used by translate(CODE[,PARAMETERS])
    • errors

      • global and package only (cannot be specified per asset)
      • kept in lang_errors.xml
      • used by trigger_localised_error(CODE, LEVEL)
  5. Installation, upgrades

    • Run step 3 when attributes are updated (types changed, new attrs added)
    • Re-compile locale when updating strings, edit screen layouts
    • No need to run install steps when function contents/logic change, effect is visible immediately
Debugging Code
  • bam($item) and minibam($item, $name) -- global functions that output contents of a variable to screen
  • log_dump($item) -- dumps item structure to the error log (data/private/logs/error.log). inspect the log by tailing it 'tail -f data/private/logs/error.log'
Further Information