Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## org.apache.tapestry5.ioc.def
Interface DecoratorDef

All Known Subinterfaces:
  DecoratorDef2

All Known Implementing Classes:
  DecoratorDefImpl

    public interface DecoratorDef

Definition of a service decorator, which (by default) is derived from a service decorator method.

A note on decorator scheduling. The scheduling is based on the desired order of behavior. Thus, if logging should occur before security checks, and security checks should occur before transaction management, then the desired decorator order is Logging, Security, Transactions. This might be specified as having Security occur after Logging, and Transactions occur after Security. It might also be specified by having Logging ordered "before:*", and Transactions ordered "after:*" with no specified scheduling for Security.

Once this order is established, decorators are applied in reverse order. Each decorator's job is to create an interceptor for the service, that delegates to the next implementation. This implies that the decorators are executed last to first. In the above example, the core service implementation would be passed to the Transaction decorator, resulting in the Transaction interceptor. The Transaction interceptor would be passed to the Security decorator, resulting in the Security interceptor. The Security interceptor would be passed to the Logging decorator, resulting in the Logging interceptor. Thus at runtime, the Logging interceptor will execute first, then delegate to the Security interceptor, which would delegate to the Transaction interceptor, which would finally delegate to the core service implementation.

Service decorators are part of the initial version of Tapestry IoC. Starting in release 5.1, their use has been deprecated, in favor of `AdvisorDef`, which is based on `AspectInterceptorBuilder`.

Note: service decorators are applied around the interceptor generated via any `AdvisorDef`s (for compatibility with Tapestry 5.0). In general, you should use service decoration or service advice, not both.

Method Summary
`ServiceDecorator` | `createDecorator(ModuleBuilderSource moduleSource, ServiceResources resources)` Creates an object that can perform the decoration (in the default case, by invoking the decorator method on the module class or instance.
`java.lang.String[]` | `getConstraints()` Returns zero or more ordering constraint strings, used to order the decorated relative to the other decorators.
`java.lang.String` | `getDecoratorId()` Returns the id of the decorator, which is derived from the decorator method name.
`boolean` | `matches(ServiceDef serviceDef)` Used to determine which services may be decorated by this decorator.

Method Detail

### getDecoratorId

    java.lang.String getDecoratorId()

  Returns the id of the decorator, which is derived from the decorator method name.

### getConstraints

    java.lang.String[] getConstraints()

  Returns zero or more ordering constraint strings, used to order the decorated relative to the other decorators.

### createDecorator

    ServiceDecorator createDecorator(ModuleBuilderSource moduleSource,
                                     ServiceResources resources)

  Creates an object that can perform the decoration (in the default case, by invoking the decorator method on the module class or instance.

  Parameters:
    `moduleSource` - access to the the module instance associated with the module containing the decorator (not necessarily the module containing the service being decorated)
    `resources` - the resources visible to the decorator (which may be in a different module than the service being decorated). Other resource properties (serviceId, serviceInterface, log, etc.) are for the service being decorated.

### matches

    boolean matches(ServiceDef serviceDef)

  Used to determine which services may be decorated by this decorator. When decorating a service, first the decorators that target the service are identified, then ordering occurs, then the `ServiceDecorator`s are invoked.

  Parameters:
    `serviceDef` -
  Returns:
    true if the decorator applies to the service

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

Copyright © 2003-2012 The Apache Software Foundation.