[CONF] Apache Tapestry > Application Module Class Cheat Sheet

[confluence]

Application Module Class Cheat Sheet Page edited by Bob Harner Comment: Added {scrollbar} to bottom Changes (1) ... _content under development_ {scrollbar} Full Content   Cheat Sheets  Component Cheat Sheet Naming conventions The bind method Service builder methods Contribute methods Unordered Decorate methods Annotations Parameter types Configuration parameter types Link to services Symbols Load services on registry startup Define service scope Disambiguate services With service Id With Markers Override existing services Related Articles Page: Response Compression Page: IoC cookbook - Service Configurations Page: Tapestry IoC Configuration Page: Symbols Page: Configuration Page: Application Module Class Cheat Sheet The Application Module class is a plain Java class. A system of annotations and naming conventions allows Tapestry to determine what services are provided by the module to your application. This is the place where you bind your custom implementation of services, contribute to, decorate and override existing services. For complete documentation, you should refer to the IOC Service guideline. Naming conventions The use of naming conventions implies that every public method of your module class should be meaningful to Tapestry: it either should follow the naming conventions, or should have an appropriate annotation. Any extra public methods will result in startup exceptions ... this helps identify methods names that have typos. Methods should be public and, preferably static. Allowing for non-static methods may have been a design error, a kind of premature optimization. The thinking was that the module could have common dependencies that it could then easily access when building services. This was partly about runtime efficiency but mostly about reducing redundancy in the various service building, contribution, and decorating methods; the ServiceBinder came later, and was a better solution (trading runtime efficiency for developer ease of use). The bind method 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); } } Allowing Tapestry to instantiate your service implementations means that, during development, they will live-reload. Of course, you can make repeated calls to ServiceBinder.bind(), to bind additional services. Service builder methods 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 the service interface is Indexer. Tapestry IoC doesn't know about the IndexerImpl class (the service implementation of the Indexer service), but it does know about the build() method. Since Tapestry isn't instantiating the implementation class, there is no possibility of live class reloading. 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; } What's important in this example is that ClasspathAssetFactory, the implementation class, implements the InvalidationListener interface. AssetFactory, the service interface, does not extend the InvalidationListener interface. 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; } Contribute methods One of the key concepts on Tapestry IoC is distributed configuration to provide extensibility and modularity. The distributed part refers to the fact that any module may make contributions to any service's configuration. The extensibility comes from the fact multiple modules may all contribute to the same service configuration. There exist three styles of configuration with matching contributions, and every Tapestry service is marked with an annotation to indicate the type of configuration it requires Unordered Services will be annotated with @UsesConfiguration. 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); } Decorate methods content under development Annotations Main Article: Annotations Tapestry 5.2 comes with a set of annotations to better your understanding of module classes. content under development Parameter types These methods may have any number of parameters, tapestry will try to resolve each parameter value as a configuration element or a registry element. Configuration parameter types content under development Link to services content under development Symbols Main Article: Symbols content under development Load services on registry startup content under development Define service scope content under development Disambiguate services content under development With service Id content under development With Markers content under development Override existing services content under development   Cheat Sheets  Component Cheat Sheet Change Notification Preferences View Online | View Changes