Mura ORM Configuration - Mura Docs v7.0

Mura ORM Configuration

Mura employs a "convention over configuration" design paradigm for registering ORM objects/entities. So, instead of creating configuration files to describe the details of where your objects/entities reside, and how to instantiate them, Mura uses a convention-based approach. In other words, by placing your objects/entities in specifically named directories, you don't have to manually or explicitly register your entities.

Model Directory

Under the hood, Mura simply leverages DI/1, a simple convention-based dependency injection (inversion of control) framework. As such, any .CFC discovered under the "../model" directories identified below will automatically get registered with DI/1.

  • {context}/{SiteID}/includes/model/
  • {context}/{SiteID}/includes/themes/{ThemeName}/model/
  • {context}/{SiteID}/includes/themes/{ThemeName}/content_types/{Type}/model/
  • {context}/{SiteID}/includes/themes/{ThemeName}/content_types/{Type}_{Subtype}/model/
  • {context}/{SiteID}/includes/themes/{ThemeName}/display_objects/{DisplayObject}/model/

You may also register any directory you want by using m.globalConfig().registerModelDir({dir}). The "dir" parameter is a logical path to a CFML directory.

This is typically done in the onApplicationLoad event. This is useful for plugins, since Mura does not automatically scan for a "model" directory in plugins, since some plugin developers may be using their own bean factory, and do not need Mura to auto-register them.

public any function onApplicationLoad(m) {
  // This is how you could register a 'model' directory in a plugin
  arguments.m.globalConfig().registerModelDir('/pluginName/path/to/your/model/');
}

All registered objects/entities are essentially "global" in the sense that they'll all use the same underlying database tables. So, you'll want to avoid describing the same entities in multiple sites. We'll cover more about entities in the Mura ORM Entity section.

The "beans" Directory

Any .CFC's discovered under "../model/beans/" will be registered as "transient" objects, not as "singleton" objects.

  • Transient objects exist only for a request and then are discarded. In other words, you et a new copy every time.
  • Singleton objects are shared among all threads and requests. In other words, there's only one of them, and you're not getting a new copy every time. These are great for "service" type objects.

The examples below show how you could register multiple transient objects.

  • ../model/beans/person.cfc
  • ../model/beans/personaddress.cfc
  • ../model/beans/personphonenumber.cfc

The "handlers" Directory

Any .CFC's discovered under a "../handlers/" directory within a "model" directory, will be registered as custom event handlers. The examples below show how you could register multiple custom event handlers, in various locations.

  • ../model/handlers/myhandler.cfc
  • ../model/services/handlers/myhandler.cfc

Registration

In order for Mura to discover these directories, and any subsequent changes you make to the directories or files contained within them, you'll need to reload Mura.

Also, the first time you reload, and anytime you add new properties to your entities, you'll need to append "&applydbupdates" to the URL in order for Mura to parse your objects/entities and make the appropriate changes to the database schema.