Models

For an ODM to be useful in large applications, we need to be able to define our own domain models.

Luckily, Paradox provides a means for you to do so. And if you don't want to, that's fine too, because Paradox will automatically wrap pods around a GenericModel if it can't find any model to wrap around the pod.

Model Formatter

Note: We have made some backwards compatibility breaking changes for this feature in 2.1.0. The new implementation is described below.

To let Paradox know what model to instantiate when a pod is dispensed, it will need a model formatter. The model formatter implements Paradox\IModelFormatter and is injected into the client:

$formatter = new MyFormatter();
$client->setModelFormatter($formatter);

The formatter contains 1 method formatModel which takes 2 values:

• The pod that is being dispensed. The pod will contain all the data as well as the type.
• The second parameter is isGraph. This let's you distinguish whether the connection is managing a graph, so you can use a special set of models.

Your implementation needs to return a string containing the full namespaced name of the class for the model.

Note that your models will need to extend the Paradox\AModel class.

For example, here's a quick example that uses models for vertices, edges and collections:

class DefaultModelFormatter implements IModelFormatter
{
    public function formatModel($pod, $isGraph)
    {
        return '\\MyModels\\' . $pod->getType();
    }
}

As can be seen, formatModel() receives the $pod and $isGraph parameters, you can use these values to determine the appropriate model to use and return its class name. In this case, if the collection requested is named Users, Paradox will use the \MyModels\Users model.

Model Events

Paradox has a neat event system so that your models can act during the lifecycle of a pod. These events will then call a specific method inside your model, if it exists.

The current list of events are:

• afterDispense() - Called after the pod is instantiated
• afterOpen() - Called after data has been loaded into the pod after retrieving it from the server.
• beforeStore() - Called before the pod is stored.
• afterStore() - Called after the pod is stored.
• beforeDelete() - Called before the pod is deleted.
• afterDelete() - called after the pod is deleted.

An example of a model:

class myModel extends Paradox\AModel{
   public function afterDispense(){
      var_dump('pod dispensed!');
   }

   public function afterOpen(){
      var_dump('data loaded!');
   }

   public function beforeStore(){
      var_dump('Pod is about to be sent to the server!');
   }

   public function afterStore(){
      var_dump('Pod is now saved on the server!');
   }

   public function beforeDelete(){
      var_dump('Pod is about to be deleted from the server!');
   }

   public function afterDelete(){
      var_dump('Pod is deleted from the serer!');
   }

   public function myCustomMethod(){
      //Do awesome things :)
   }
}