Ariadne delegates a lot of functionality to seperate modules. These modules can be loaded and used in PINP templates when needed. One of these modules is the database module. A sample template using this module looks like this:

<pinp>
  load("mod_db.php");
  $db = DB::connect("mysql://user@localhost/database");
  if ( DB::isErroR( $db ) ) {
     echo DB::errorMessage( $db );
  } else {
    $db->setFetchMode( DB_FETCHMODE_OBJECT );
    $query  = "select * from MyTable"; 
    $result = $db->query( $query );
    if ( DB::isError( $result ) ) {
      echo DB::errorMessage( $result ); 
    } else {
      // do something with the results
    }
  }
</pinp>

The second line in the template above loads the database module, mod_db. This module is basically a wrapper for the PEAR DB library. It allows you to connect to virtually any kind of database server and run queries on it. See the documentation for PEAR DB, at the pear.php.net website for more information.

Building your own module

A module is class or set of classes, specifically designed to work in PINP templates. This means that a module is safe and won't allow access to disk or the ariadne database directly.

When creating a new module for use in pinp templates, there are a few rules to follow. Each class you want to be able to use in a PINP template should have a prefix of 'pinp_'. So the class DB used above, is translated to pinp_DB in the module code.

In addition each method of the class (except for constructors) that is accessible in PINP, should have a prefix of '_'. Again in the class DB user above, the connect() function is defined as '_connect()' in the module code.

Another thing to remember is that the 'new' operator is disabled in PINP, so if you want to instantiate a class, you must provide a 'factory' method, which returns the new object, just like connect() does in the DB module.

Finally, you should always take care that methods in your module do not allow a user to circumvent the security model of Ariadne. Specifically it should never allow direct disk access, or database access, without extensive checks. In the DB case, connection id's used to connect to the database are not accessible by PINP templates, and therefor cannot be changed to access the store database directly.

Example module:

<?php
  class world {
    function hello() {
      echo 'hello world';
    }
  }

  class pinp_world {
    function _hello() {
      return world::hello();
    }
  }
?>