Chapter 4. Configuration

Table of Contents

4.1. Introduction
4.2. Formal Definition
4.2.1. The monorail Node
4.2.2. The controllers Node
4.2.3. The viewcomponents Node
4.2.4. The viewEngine Node
The additionalSources Node
4.2.5. The services Node
4.2.6. The extensions Node
4.2.7. The routing Node

4.1. Introduction

MonoRail requires a small configuration on your web.config . This document should help you to understand the whole configuration schema in details.

The following is a standard minimal configuration required to get MonoRail working with all defaults. Unfortunatelly the project assembly name must be informed (we cannot infer it).

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <configSections>
        <section 
			name="monorail" 
			type="Castle.MonoRail.Framework.Configuration.MonoRailSectionHandler, Castle.MonoRail.Framework" />
    </configSections>
    
    <monorail>
        <controllers>
            <assembly>ProjectAssembly</assembly>
        </controllers>
    </monorail>
    
    <system.web>
        <httpHandlers>
            <add 
				verb="*" 
				path="*.rails" 
				type="Castle.MonoRail.Framework.MonoRailHttpHandlerFactory, Castle.MonoRail.Framework" />
        </httpHandlers>
        <httpModules>
            <add 
				name="monorail" 
				type="Castle.MonoRail.Framework.EngineContextModule, Castle.MonoRail.Framework" />
        </httpModules>
    </system.web>
</configuration>

This configuration defaults to use the WebForms view engine and uses the ProjectAssembly as the source of controllers and ViewComponents.

Note

The section monorail must be declared on the configSections .

4.2. Formal Definition

The following exposes all available nodes. It can be used to extend and change the default MonoRail behavior by supplying custom implementation of services.

<monorail 
	useWindsorIntegration="true|false"
	checkClientIsConnected="true|false"
	smtpHost="" smtpPort="" 
	smtpUsername="" smtpPassword="" 
	>
	
	<!-- 
	  Custom Factories should be configured on the services node. 
	  The following is supported to be backward compatible
	-->
	
	<customControllerFactory type="type name that implements IControllerFactory" />
	<customComponentFactory type="type name that implements IComponentFactory" />
	<customFilterFactory type="type name that implements IFilterFactory" />

	<controllers>
		<assembly>AssemblyName1</assembly>
		<assembly>AssemblyName2</assembly>
	</controllers>
	
	<viewcomponents>
		<assembly>AssemblyName1</assembly>
		<assembly>AssemblyName2</assembly>
	</viewcomponents>
	
	<viewEngine 
		viewPathRoot="views" 
		customEngine="ViewEngine.Type.Name, Assembly">
		
		<additionalSources>
			<assembly name="" namespace="" />
			<assembly name="" namespace="" />
		</additionalSources>
		
	</viewEngine>

	<!-- List of services ids:

			Custom
			ControllerFactory
			ViewEngine
			ViewSourceLoader
			ViewComponentFactory
			FilterFactory
			ResourceFactory
			EmailSender
			ControllerDescriptorProvider
			ResourceDescriptorProvider
			RescueDescriptorProvider
			LayoutDescriptorProvider
			HelperDescriptorProvider
			FilterDescriptorProvider
			EmailTemplateService
			ControllerTree
			CacheProvider
			ScaffoldingSupport
			ExecutorFactory
			TransformFilterDescriptorProvider
			TransformationFilterFactory
			ViewEngineManager
			UrlBuilder
			UrlTokenizer
			ServerUtility
			ValidatorRegistry
			AjaxProxyGenerator
	-->
	
	<services>
		<service 
			id="[see list above]" 
			type="Service.Type.Name, Assembly"
			interface="optional" />
	</services>
	
	<extensions>
		<extension type="Extension.Type.Name, Assembly" />
		<extension type="Extension.Type.Name, Assembly" />
	</extensions>

	<routing>
		<rule>
			<pattern>(/blog/posts/)(\d+)/(\d+)/(.)*$</pattern>
			<replace><![CDATA[ /blog/view.rails?year=$2&amp;month=$3 ]]]]></replace>
		</rule>
		<rule>
			<pattern>(/news/)(\d+)/(\d+)/(.)*$</pattern>
			<replace><![CDATA[ /news/view.rails?year=$2&amp;month=$3 ]]]]></replace>
		</rule>
	</routing>
	
</monorail>

4.2.1.  The monorail Node

AttributeDescription
useWindsorIntegration Enables Windsor Container integration
checkClientIsConnected Enables checks for client connection that stops the process if the client has disconnected
smtpHost The smtp host, if there is intention to use MonoRail e-mail features
smtpPort The smtp port, if it is not using the default port
smtpUsername The smtp username (if it requires authentication)
smtpPassword The password (if it requires authentication)

4.2.2.  The controllers Node

The controller node takes one or more assembly nodes. The assembly names are used during initialization as MonoRail will inspect them for controllers to construct a tree.

Note

This node is only used by the default controller factory. It may be ignored by different factories. For example, if Windsor Container integration is enabled, the node will be ignored.

4.2.3.  The viewcomponents Node

The viewcomponents node takes one or more assembly nodes. The assembly names are used during initialization as MonoRail will inspect them for ViewComponents to initialize a dictionary.

Note

This node is only used by the default controller factory. It may be ignored by different factories. For example, if Windsor Container integration is enabled, the node will be ignored.

4.2.4.  The viewEngine Node

The viewEngine node informs MonoRail of the views folder (which may be a relative or an absolute path) and allows the programmer to specify a custom implementation of IViewEngine .

AttributeDescription
viewPathRoot The folder that contains the views
customEngine Full .net type name of a type that implements IViewEngine

The additionalSources Node

Some view engines implementation allow you to use assemblies resources to store views, beside the file system. This is a good approach to reuse controllers among projects.

AttributeDescription
name The assembly name (without extension)
namespace Resources can have a namespace in their names. The namespace must be informed so it can be stripped to allow MonoRail to find the view content as it was in the file system.

4.2.5.  The services Node

MonoRail is composed of a few services. They can be replaced by custom implementations.

AttributeDescription
id The service id used internally by MonoRail
type The implementation type name
interface If the service is defined by an interface contract, it should be specified on this attribute.

4.2.6.  The extensions Node

Extensions can be added. They hook some events exposed by MonoRail to act on them augmenting its functionality.

An extension must implement the IMonoRailExtension interface.

4.2.7.  The routing Node

Routes can be added to define rewrite rules for the urls. This allow nicer urls but can only be used under some conditions.