Warning This documentation has been moved to docbook format and now resides on the Spring.NET website. If you feel the need to edit this document please send and email to the Spring.NET developer list.

Because Spring.Web uses code behind class for the page as a controller, it was important for us to allow Spring IoC container to inject dependencies into page instances. This allows you to inject all service dependencies using standard Spring configuration instead of relying on custom service locators or manual object lookups in Spring application context.

Once you have configured Spring application context, you can easily create object definitions for the pages:

<objects>

  <object id="masterPage" type="~/Master.aspx" />
  
  <object id="basePage" abstract="true">
      <property name="Master">
          <ref object="masterPage" />
      </property>
  </object>
    
  <object type="Login.aspx">
      <property name="Authenticator">
        <ref object="authenticationService"/>
      </property>      
  </object>
    
  <object type="Default.aspx" parent="basePage"/>

</objects>

This example contains four definitions:

1. First definition specifies which page should be used as a Master Page.
2. Second definition is an abstract definition for the base page that many other pages in the application will inherit from. In this case, it simply specifies which page should be used as a master page.
3. Third definition is for a login page that neither inherits from the base page nor uses master. It does show however how to inject a service into a page instance.
4. Last definition is for a default application page. In this case it simply inherits from basePage in order to have master, but it doesn't need any additional configuration.

Type name is the name of the .aspx file, relative to the directory context it is defined in. In the example above, definitions are in the root context so Login.aspx and Default.aspx should be in the root of the application as well. Master page is defined using absolute path because it can be referenced from child contexts that are defined within subdirectories of the application.

You will also notice that definitions for Login and Default pages don't have neither id nor name. This is actually intentional, as we generally want to use the page name as an identifier. If an id is not specified Spring will simply extract the page name without path and extension from the type name and use it as an identifier.

Of course, nothing prevents you from specifying id explicitly, and it actually might be useful if you want to expose same page multiple times using slightly different configuration (Add/Edit pages for example).

Injecting Dependencies into Controls

Spring also allows you to inject dependencies into controls (user controls or standard controls) that are contained within the page. You can accomplish this in two ways – either globally for all the controls of the particular type, or locally, for the specific control within the page.

In order to inject dependencies globally, you need to specify fully qualified control type name (without the assembly) as object definition identifier:

<object id="MyProject.MyControl" abstract="true">
   ...
</object>

On the other hand, in order to inject dependencies locally, you need to specify control's UniqueID as the object identifier:

<object id="myContainerControl:myTargetControl" abstract="true">
   ...
</object>

In either case, be sure to mark the object definition as abstract via the use of the abstract="true" attribute.

Obtaining UniqueID for the Control The easiest way to obtain control's UniqueID is by turning tracing on for the application and by looking for the ID in the control hierarchy section of the page trace.

You can specify both global and local definition for the same control, in which case definitions will be merged, with values from the local definition overriding values from the global definition as necessary.

Due to context scoping issues, you will probably want to define your global control definitions in the root context so values are injected consistently throughout the application. On the other hand, you will probably want to put your local control definitions within the child context for the component, in order to avoid naming conflicts between different components.

Limitations of Control Injection Unfortunately, it is currently impossible to inject dependencies into controls before their Init event is fired, which means that you cannot use any of the injected values within the control's OnInit method (or event handler for the Init event). Dependencies are injected after Init event but before Load event, which means that the handler for the Load event is the first place in the code where you can safely use injected variables.