Tapestry IoC

...

Configuration

Tapestry services – both those provided by Tapestry and those you write yourself – are configured using Java, not XML.

One of the key concepts on in Tapestry IoC is distributed configuration. This is a concept borrowed from the Eclipse Plugin API and evidenced in Apache HiveMind prior to Tapestry 5 IoC.

So ... nice term, what does it mean?

The distributed part refers to the fact that any module may configure a service. Distributed configuration is the key feature of Tapestry IoC that supports extensibility and modularity.

The distributed part refers to the fact that any module may make contributions to any service's configuration.

Modules configure a service by contributing to service configurations. This seems esoteric, but is quite handy, and is best explained by an example.

Say you are building a service that, say, maps a file extension to an interface called FileServicer. There's Let's say you've written a bunch of different services, all implementing the FileServicer interface, across many different modules, each doing of which does something specific for a particular type of file (identified by the file's extension).A central service uses this configuration to select a particular FileService interface, and each implements the same interface, which we'll call FileServicer. And now let's say you need a central service that selects the one of your FileServicer implementations based on a given file extension. You start by providing a service builder method:

  public static FileServiceDispatcher buildFileServicerDispatcher(Map<String,FileServicer> contributions)
  {
    return new FileServiceDispatcherImpl(contributions);
  } 

...

So where do the values come from? Service Your service contributor methods, methods that whose names start with "contribute":

  public static void contributeFileServicerDispatcher(MappedConfiguration<String,FileServicer> configuration)
  {
    configuration.add("txt", new TextFileServicer());
    configuration.add("pdf", new PDFFileServicer());
  }  

Like service builder and service decorator methods, we can inject services if we likeOr, instead of instantiating those services ourselves, we could inject them:

  public static void contributeFileServicerDispatcher(MappedConfiguration<String,FileServicer> configuration,
  
    @InjectService("TextFileServicer") FileServicer textFileServicer,
    
    @InjectService("PDFFileServicer") FileServicer pdfFileServicer,)
  {
    configuration.add("txt", textFileServicer);
    configuration.add("pdf", pdfFileServicer);
  }  

...

• It makes it much easier for an override of the service to get the configuration intended for the original service.

The following example is an annotation-based alternative for the contribution method above.

...

There are three different styles of configurations (with matching contributions):

• Unordered Collection. – Contributions are simply added in and order is not important.
• Ordered List. – Contributions are provided as an ordered list. Contributions must establish the order by giving each contributed object a unique id, by establishing forward and backward dependencies between the values.
• Map. – Contributions provide unique keys and corresponding values.

...

No annotation is needed for these cases.

Configuration Overrides

...