Page History

{scrollbar}

...

For complete documentation, you should refer to the IOC Service guideline.

...

Every module may have an optional, static bind() method which is passed a ServiceBinder. By using the ServiceBinder, you will let Tapestry autobuild your services. Autobuilding is the preferred way to instantiate your services.

package org.example.myapp.services;

import org.apache.tapestry5.ioc.ServiceBinder;

public class MyAppModule
{
  public static void bind(ServiceBinder binder)
  {
    binder.bind(Indexer.class, IndexerImpl.class);
  }
}

...

Sometime you need to do more than just instantiate the class with dependencies. It is common inside Tapestry for one service to be a listener to events from another service. In that situation (or other similar ones), a service builder method is useful, as it shifts control back to your code, where you have the freedom to perform any additional operations necessary to get the service implementation up and running.

package org.example.myapp.services;

public class MyAppModule
{
  public static Indexer build()
  {
    return new IndexerImpl();
  }
}

...

Here's a more complicated example:

    @Marker(ClasspathProvider.class)
    public static AssetFactory buildClasspathAssetFactory(ResourceCache resourceCache,
            ClasspathAssetAliasManager aliasManager, AssetPathConverter converter)
    {
        ClasspathAssetFactory factory = new ClasspathAssetFactory(resourceCache, aliasManager, converter);

        resourceCache.addInvalidationListener(factory);

        return factory;
    }

...

Tapestry has evolved some additional tools to "have your cake and eat it too"; the @Autobuild annotation takes care of instantiating a service implementation, with dependencies, allowing your code to focus on the extra initialization logic, and not on the dependencies:

    public static PersistentFieldStrategy buildClientPersistentFieldStrategy(LinkCreationHub linkCreationHub, @Autobuild
    ClientPersistentFieldStrategy service)
    {
        linkCreationHub.addListener(service);

        return service;
    }

...

For example, here's a kind of tapestry internal service that requires a list of Coercion tuples to be able to coerce values from one type to another (i.e. from string to the target type when reading values from the HTTP request)

public TypeCoercerImpl(Collection<CoercionTuple> tuples)
{
    // ...
}

On the contribution side, a service contribution method sees a Configuration object:

public static void contributeTypeCoercer(Configuration<CoercionTuple> configuration) {
{
    // Create Coercion tuple here
    // ...

    configuration.add(myTuple);
}

...

content under development

{scrollbar}